opensuse DNS delays

The last few days since I installed openSUSE 11.4, I've had really frustrating delays with certain DNS lookups. zypper, for example, was taking 4-5 seconds to resolve each host when refreshed, particularly annoying if one just wants to search for a package and is forced to sit through a 2 minute delay. Happily, it is now resolved. Thanks to the discussion under this bug, I learned that placing the line "options single-request" (without quotes) in /etc/resolv.conf solved the issue. According to man 5 resolv.conf, this forces glibc to perform the IPv6 and IPv4 requests sequentially, and not not in parallel which can cause timouts with certain DNS servers and then the delays I was seeing.

Of course, you could also run nscd, which I don't for certain reasons, but still, all DNS lookups ought to be fairly instantaneous. Hope this helps someone. :)

SonicWALL SSL-VPN NetExtender and openSUSE

Seems the "stable" version of SonicWALL's NetExtender (3.5.632 at time of writing) does not play nicely with my installation of openSUSE 11.3. I didn't have much luck with 11.2 either, but to be honest, I didn't really go into how to fixing it. Anyhow, I hadn't looked at it in a while as it's not critical, but I needed to get some work done tonight from home, so I tried again. Still, no luck:

netExtenderGui [19:29]
2010-08-31 19:30:05 BST INFO com.sonicwall.NetExtender Logging initialized.
2010-08-31 19:30:06 BST INFO com.sonicwall.NetExtender NetExtender version 3.5.632
Making a global reference ot the NetExtenderControl object registered with JNI
SUSE/Ubuntu compatibility mode on
printlog: first getting class id
printlog: getting printTologFromJNI method id
Found method id
,,,,,,,,,,,,,,,
,,,mmbbbbbb11111111111111111111111bbbbbmm,,,
,,,b||PPPPPPP||````````````````|PPPPPPPPP111111111111bbm,,
`````` `````PPPP111111111bm,
```PP1111111bm,
`PP111111b,
|111111:
NetExtender for Linux - Version 3.5.632 .1111P|.
Copyright (c) 2009 SonicWALL, Inc. ,b1PP|`
,,||```
Loading saved profiles...
JNI: setDestination:Setting Destination: ssl.--redacted!--.com (port 443)
JNI: LaunchNX: mypid = 12448
JNI: LaunchNX: Launching NetExtender2
JNI: LaunchNX: Using destination IP ssl.--redacted!--.com
JNI: LaunchNX: launching NX

Connecting to SSL-VPN Server "ssl.--redacted!--.com:443". . .
Connected.
Logging in...
Login successful.
Using SSL Encryption Cipher 'DHE-RSA-AES256-SHA'
Using new PPP frame encoding mechanism
SSL-VPN logging out...
SSL-VPN connection is terminated.
Exiting NetExtender client
JNI: LaunchNX: Exiting LaunchNX, returning (0)
Loading saved profiles...
2010-08-31 19:30:54 BST INFO com.sonicwall.gui.NetExtenderRootPanel NetExtender disconnected
JNI: LaunchNX: mypid = 12448
JNI: LaunchNX: Launching NetExtender2
JNI: LaunchNX: Using destination IP ssl.--redacted!--.com
JNI: LaunchNX: launching NX

And so on, it looped and looped before finally giving up. I discovered, through this Ubuntu forum, that there is an updated, albeit a pre-release, version, namely 4.0.665. This version doesn't seem to be readily available on the mysonicwall.com site, even when logged in, as stated by some users. It is, however, easily obtainable by visiting SonicWALL's demo site, https://sslvpn.demo.sonicwall.com and selecting the NetExtender icon. From there, you can unzip the file, and install as root or with sudo with a ./install in the resultant netExtenderClient folder. Agree to the auto-repair which is essentially just creating a symlink from /lib/libssl.so.6 -> /lib/libssl.so.1.0.0.

The installer may ask if you want to run the app as route. Since received wisdom states that this is generally a bad idea, and will require further steps when you run the app, say no to this option. This will, however, mean that you will need to make sure that pppd itself is setuid root. The installer ought to take care of this if you add "fixppp" as the first argument , or it is simply achieved with the following command:

chmod 4755 /usr/sbin/pppd

Once done, you ought to be able to run the pre-release version, using either the command netExtenderGui from the command line, or by copying /usr/share/netExtender/NetExtender.desktop to somewhere convenient and running that instead.

Fantec MM-HDRL and Linux

Just bought myself a Fantec MM-HDRL. It's a well designed, compact piece of hardware that is badly let down by the accompanying firmware, and is a particular disappointment to this long time linux user for reasons both idealogical and practical.

Without going into too much extraneous detail, I shall just say that the interface is butt-ugly and somewhat slow to read folders of one's own media, but simple and intuitive enough to get by without recourse to the manual. RTFM? Only if strictly necessary.

My first issue with the device, albeit one of which I was already aware before making the purchase, was that it supports only two types of file system for the media partition, NTFS and FAT32, both of which have their limitations for me. FAT is obviously well out of date, what with its file size and name length limitations, and NTFS support under Linux isn't all that it could be, particularly the issues that occur when the partition is not shut down cleanly and there is no Windows machine with which to run a repair. As I said, this was something I knew when I made the purchase, but it was slightly galling to find out as I did later that the root filesystem of the firmware was trusty old ext3, along with the usual tools mkfs.ext3 and fsck.ext3. It seems, then, rather churlish to utilise the filesystem of choice for many linuxers and indeed the choice of the programmers of the MM-HDRL, but not include this as an option for the media partition. I did reformat as ext3, in the hope that it would just work, albeit without any official support, but the media browser was unable to see anything on the partition after that, so I had to revert to FAT.

Secondly, I was somewhat gobsmacked to find that the box is accessible on the network, via telnet, for users root, nobody, and guest, all without a password. Once in, setting said passwords, or indeed trying to tighten up security in any way is futile as the firmware is of course read-only. It does mean however that restricting access to the box on your local network is all but futile.

It turns out that there are a group of hackers working on ways to unload the firmware into a directory so things like root passwords and ssh can be added. The only problem is that the source for this is unavailble as far as I can see, requires windows, and the downloads are apparently recognized by several antivirus softwares as containing a virus. In spite of the protestations of the developers that this is a result of false positives, it does mean that you have to take their word for it against your AV program - hmmmm. And that's assuming you actually have a copy of Windows which in my case is a negative. Not for me, thank you. That stuff is all here, but, at the time of writing, a post asking for the sources, and the developer declining to publish them (which may have changed), is unavailable.

All in all, it's not a terrible piece of equipment but there are many little niggling issues that could be put right. In fact, it probably wouldn't hurt the owners of the device to open source it themselves and see if they can build up a community of hackers working on improving it.

Fuck Toshiba

A colleague of mine brought me his borked personal laptop the other day. I was to determine that the hard drive had failed, causing a fair amount of data loss, but otherwise all seemed ok with the rest of the laptop. On the face of it, simple enough - replace the 2.5 inch SATA drive and reinstall Vista. Ha! I hadn't counted on corportate shitbags Toshiba, from whom I will never knowingly purchase another component.

The lappy came without any Vista disks, just a self restoring program on a separate partition of the hard disk drive, which of course was failing due to the disk corruption. At this stage I phoned Toshiba to see if I could get a replacement Vista disk from them. I ended up dealing with some strategically shaved chimp who told me that, as the customer hadn't taken any backups, we would need to purchase a restore disk for 30 squids. Well, that did it. Off to the Pirate Bay to get something that my colleague had actually paid for and had a license for already. (And via about 30 rootkit scanner sites too for post-install)!

My thoughts on this are threefold. Firstly, fuck Toshiba (and any other vendors who do pull this kind of underhand shit). The person to whom the laptop belongs is a little clueless, but this is just taking the piss. Secondly, always check before you purchase a Windows machine that you are getting a full Windows install disk in case you have to replace your hard drive. Otherwise you are going to end up paying another £30 odd for something you already thought you owned. And finally, at least there are alternatives and thank Cliff* I haven't had to use Windows in my personal or professional life for some years now.

* ref, The Young Ones

MS-DOS Codepage 850 to ISO 8859-14

Different character sets, don't you love 'em. Today I had to deal with some exported text that was DOS encoded (Codepage 850 to be precise), that was needed in ISO 8859-14 encoding. Luckily, this sort of thing is pretty straightforward in Linux.

On the command line, glibc provides a fantastic converter called iconv. Invoking it is as simple as this:

iconv --from-code=CP850 --to-code=ISO-8859-14 \
original_file > converted file

In my case, I need to incorporate this into a python script. Luckily, python makes this very simple without having to resort to third party tools. Once you've read in your text, encode it into unicode and further encode it into your desired charset.

converted_text = unicode(original_txt, \
'cp850').encode('iso8859_14')


OpenOffice.org Proper / Title Case

Today I had to convert thousands of lines of text in OpenOffice Calc to title/proper case. I could have scripted it, but it felt like OpenOffice *should* have this sort of functionality built it. Under the Format->Change Case menu options, there are Uppercase/Lowercase options, but no title/proper case.

I found a couple of old macros that purportedly did the job - they didn't work and I really didn't fancy fucking about with VBScript or whatever the hell it is. In my case, the simplest way to do this was to create a neighbouring column and enter =PROPER(A1) with A1 being the neighbouring cell. Copy this simple formula down the rest of the column, copy the values and paste-special the strings. Simples!

I'm sure there are more elegant ways to do this but I had a deadline and I didn't really fancy any extra legwork, just to get the values converted. Hopefully this will save someone some time dicking about with macros that don't work and other such irritants.

swaks, an SMTP transaction tester

I'm indebted to Debian Administration for alerting me to a tool which would have saved me a huge amount of time if I'd known of its existence earlier, namely swaks, an SMTP transaction tester. Ever get sick to death of typing and retyping an SMTP conversation into a malfunctioning mail server? Then swaks is for you, it takes all the boring, repetitive SMTP conversations out of the equation by automating it for you and displaying the results to the command line. Hooray!

Man page here.