an openSUSE blog

opensuse DNS delays

2011-03-18T17:33:00.001Z

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

2010-08-31T21:34:00.001+01:00

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

2009-09-25T23:47:00.001+01:00

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

2009-06-30T16:14:00.001+01:00

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

2009-05-21T10:41:00.001+01:00

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

2009-05-06T00:24:00.007+01:00

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

2009-04-12T03:01:00.007+01:00

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.

Bilbo Blogger

2009-03-17T23:11:00.002Z

Hmmm.. praps this new-fangled, KDE4 blogging app Bilbo Blogger is what I need to get me out of my blogging torpor. Seems to wrestle with links somewhat, but it's early days.

Build instructions here.

simple qdbus tutorial (part two)

2008-04-17T17:33:00.009+01:00

Following on from part one of my qdbus tutorial, we move on to look into what happens when we try to manipulate a D-Bus capable application that is already running in remote session. This is not as easy as one might imagine. It's certainly not difficult, but it did take me a little while and some help off the mailing lists to work out what I wanted to do.

For demonstration purposes, I shall be logged in remotely on my home machine via ssh. If I run qdbus as per the last tutorial it fails immediately.

cm@pablo:~> qdbus Could not connect to D-Bus server: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed.

X11? WTF? This may initially seem that qdbus is dependent on an accessible X session. Indeed, if I were to log out, and login again using ssh -X this problem would go away. The big issue being that I would then be connecting to the bus on the local machine and not the remote one which I am trying to manipulate.

What's really happening here is that qdbus is looking for the all important shell variable DBUS_SESSION_BUS_ADDRESS which contains a unique address for each bus. Not finding this, it's running dbus-launch --autostart to try and determine the address by querying another X window. Of course it then fails if it is unable to connect to any X session.

The obvious way to get around this is to set this variable. But how do we determine the bus address that we need to connect to our running instance of a program? This is not difficult, but it's not the most obvious method. As far as I am aware, there is no other easy way to do this - perhaps in future versions this will become more trivial.

The first thing to do is determine the PID of the app that we are after (ktorrent as in the last example).

cm@pablo:~> ps -ef|grep -i ktorrent cm 4685 1 1 08:50 ? 00:06:17 ktorrent

So, we can see that ktorrent has a PID of 4685. Now to determine the relevant bus address being used by this program (obviously replacing the example PID with the actual one).

cm@pablo:~> cat /proc/4685/environ

This will spew out a stack of environment variables, amongst them, with any luck, the one we are after: DBUS_SESSION_BUS_ADDRESS. What we want to do is export this shell variable, so it is available to our shell session and we in turn will be able to manipulate our app:

export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-tIGLky9nbN,guid=49eaa775154aa8aa83ba330048070013"

The above will all be on one line of course (or properly escaped). Having done this, set your faces to stunned as now when you run qdbus, you are now seeing the apps on the correct bus:

cm@pablo:~> qdbus :1.0 org.ktorrent.ktorrent :1.2 org.kde.klauncher :1.3 org.kde.kded org.kde.kwalletd :1.69 :1.70 org.freedesktop.DBus

And that's the end of my introduction to qdbus!

simple qdbus tutorial (part one)

2008-04-17T14:56:00.020+01:00

If you are a reasonably seasoned user of kde, the chances are you will have encountered the Desktop COmmunications Protocol, or DCOP. Now, DCOP has many uses, it is useful for apps to communicate with each other, it is certainly handy when scripting for a GUI app. Personally I find the most useful aspect of DCOP is the ability to control GUI apps remotely, and to see what they are up to. For example, if I wish to find out what song amarok is playing on a remote machine, I can execute the following on the command line (as root):

dcop --user fred amarok player nowPlaying

Pretty nifty. But DCOP is now being phased out, and is being replaced by D-Bus. D-Bus is heavily influenced by DCOP and the basics are fairly easily learned.

This post will attempt to show how to communicate with D-Bus, specifically using qdbus. (qdbusviewer may be a topic for another time, but do have a look at it - it may be a whole lot more self-explanatory).

First off, let's see what happens when we run qdbus on its own:

cm@fool:~> qdbus :1.0 org.kde.KResourcesManager org.kde.kopete :1.2 org.kde.klauncher :1.23 :1.3 org.kde.kded org.kde.kwalletd :1.30 org.ktorrent.ktorrent :1.37 :1.38 :1.6 org.kde.kwalletmanager :1.8 org.kde.knotify org.freedesktop.DBus

That give us a list of all the applications we can manipulate using qdbus. In this instance we'll focus on ktorrent. First I want to see what objects are available in the application:

cm@fool:~> qdbus org.ktorrent.ktorrent / /KDebug /KIO /KIO/Scheduler /KTorrent /MainApplication /ktorrent /ktorrent/MainWindow_1 /ktorrent/MainWindow_1/actions /ktorrent/MainWindow_1/actions/file_new /ktorrent/MainWindow_1/actions/file_open /ktorrent/MainWindow_1/actions/file_quit /ktorrent/MainWindow_1/actions/options_show_statusbar /ktorrent/MainWindow_1/actions/options_show_menubar /ktorrent/MainWindow_1/actions/options_configure /ktorrent/MainWindow_1/actions/options_configure_keybinding /ktorrent/MainWindow_1/actions/options_configure_toolbars /ktorrent/MainWindow_1/actions/help_contents /ktorrent/MainWindow_1/actions/help_whats_this /ktorrent/MainWindow_1/actions/help_report_bug /ktorrent/MainWindow_1/actions/switch_application_language /ktorrent/MainWindow_1/actions/help_about_app /ktorrent/MainWindow_1/actions/help_about_kde

Each of these objects will have methods (functions) and variables, with which we can manipulate the program, and learn about the current status of the program.

cm@fool:~> qdbus org.ktorrent.ktorrent /KTorrent method int org.ktorrent.KTorrent.downloadSpeed(QString torrent) method void org.ktorrent.KTorrent.start(QString torrent) method void org.ktorrent.KTorrent.startAll() method void org.ktorrent.KTorrent.stop(QString torrent) method void org.ktorrent.KTorrent.stopAll() signal void org.ktorrent.KTorrent.torrentAdded(QString tor) signal void org.ktorrent.KTorrent.torrentRemoved(QString tor) method QStringList org.ktorrent.KTorrent.torrents() method int org.ktorrent.KTorrent.uploadSpeed(QString torrent) method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name) method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value) method QString org.freedesktop.DBus.Introspectable.Introspect()

This gives me a list of available methods with any required arguments in brackets. The names of many of these functions makes their use obvious, for example the org.ktorrent.KTorrent.stopAll() function will stop all active torrents. If we try it, we find out that that is indeed what happens. Similarly, qdbus org.ktorrent.ktorrent /KTorrent org.ktorrent.KTorrent.torrents will list the torrents currently being downloaded:

cm@fool:~> qdbus org.ktorrent.ktorrent /KTorrent org.ktorrent.KTorrent.torrents drivexv_drivexv.zip

As we can see, one torrent is currently being downloaded, a zip file from stereogum. A couple of things to note. Although the function description will contain brackets, the command itself must not. Arguments must be placed sequentially after the function, again without brackets.

And that's the basic usage of qdbus. Next time we'll look at doing this remotely, as the above will not work on a remote machine without tinkering a little. The reason being that you will most likely be querying a different bus to the one that is running your app.

Zenburn for Konsole Redux

2008-04-12T19:09:00.010+01:00

One of my favorite kde apps is konsole. A while ago I discovered Zenburn which is just about the only sane colorscheme for terminal editing of any sort, and especially in vim. Then I discovered that some enterprising chap had knocked together Zenburn for konsole. Seventh heaven ensued. But lately, as I've been dabbling in kde4 I've been really missing Zenburn in the new version of konsole. So I give you Zenburn for Konsole Redux, shamelessly built on the hard work of others so that you don't have to spend half your evening fiddling about with annoying colorscheme settings just to get it right.

UPDATED: Thanks to Sterling Winter who pointed out in the comments that the link no longer works. So here it is inline, hopefully blogger will react sanely as it so often doesn't with any code examples etc. :)
[Background] Bold=false Color=63,63,63 Transparency=true [BackgroundIntense] Bold=false Color=63,63,63 Transparency=true [Color0] Bold=false Color=63,63,63 Transparency=false [Color0Intense] Bold=false Color=112,144,128 Transparency=false [Color1] Bold=false Color=112,80,80 Transparency=false [Color1Intense] Bold=false Color=220,163,163 Transparency=false [Color2] Bold=false Color=96,180,138 Transparency=false [Color2Intense] Bold=false Color=195,191,159 Transparency=false [Color3] Bold=false Color=223,175,143 Transparency=false [Color3Intense] Bold=false Color=240,223,175 Transparency=false [Color4] Bold=false Color=80,96,112 Transparency=false [Color4Intense] Bold=false Color=148,192,243 Transparency=false [Color5] Bold=false Color=220,140,195 Transparency=false [Color5Intense] Bold=false Color=236,147,211 Transparency=false [Color6] Bold=false Color=140,209,211 Transparency=false [Color6Intense] Bold=false Color=147,225,227 Transparency=false [Color7] Bold=false Color=220,220,204 Transparency=false [Color7Intense] Bold=false Color=255,255,255 Transparency=false [Foreground] Bold=false Color=220,220,204 Transparency=false [ForegroundIntense] Bold=true Color=220,220,204 Transparency=false [General] Description=Zenburn Opacity=1
Copy it into ~/.kde4/share/apps/konsole/Zenburn.colorscheme and select it in the Settings->Manage Profiles->Edit Profiles Appearance tab.

And We're Off

2008-04-07T02:07:00.001+01:00

I am trying out blokkal for the first time - I think that's where previous blogging attempts slowed to a stop - not having a quick and simple local client every time I had a post in my head. This blog will be an attempt to share my experiences, good and bad, about my linux distro of choice, openSUSE. I've been using it for at least 9 years after cutting my teeth on Redhat long before it branched into Fedora, and a look at several other distros. If I remember correctly it all started with SuSE 6 point something - certainly these archives look vaguely familiar. SuSE has *traditionally* provided a slicker desktop than the competition and that's what attracted me to it in the first place, although I've had plenty of dabbling in Debian based distros since, mostly work related. Debian (and hence, Ubuntu) have traditionally had better package management and I think that remains the case, although it will be interesting to see if openSUSE's new Sat Solver manages to compete. The openSUSE Build Service will hopefully help to bridge that gap.

Anyways, interesting times ahead, with kde4 out and looking the business, although I am yet to find it useable enough to make the switch permanent - a combination of show-stopping bugs and lack of features in konsole scaring me away. I'm a kde type mostly, although I feel very comfortable on the command line and do most of my day to day work there, including use of the redoubtable mutt.

I'm afraid I've a bit of tendency towards industrial strength language from time to time. It's only words, get over it.