ssh.py provides three common SSH operations, get, put and execute. It is a high-level abstraction upon Paramiko.

I wrote it yesterday for my own needs, so it is still very much in the beta stage. Any improvements or comments gratefully accepted.

In short, it works as follows:

import ssh
s = ssh.Connection('example.com')
s.put('hello.txt')
s.get('goodbye.txt')
s.execute('du -h --max-depth=0')
s.close()

That is it, in the rest of this post, I walk through this line by line.

Installation

First, we need to install paramiko, if you don't have it already.

On Gentoo Linux:

emerge paramiko

On Ubuntu/Debian and so on:

apt-get install python-paramiko

If you want to use Python's easy_install then:

easy_install paramiko

Secondly, you need to grab the ssh.py module, grab it from my code-page, and save it as ssh.py.

Connecting to a remote server

To play with the script interactively, you need to start Python:

python

Now, import the ssh module:

import ssh

Next we need to initiate the connection. If your username is the same on both systems, and you have set up ssh-keys, then all you need to do is:

s = ssh.Connection('example.com')

Connection supports the following options:

The host is essential of course. Port defaults to 22. The username defaults to the username you are currently using on the local machine.

You need to use one of the authentication methods, a private key or a password. If you don't specify anything, then ssh.Connection will attempt to use a private_key at ~/.ssh/id_rsa or ~/.ssh/id_dsa.

So to specify a username and password, you can do it like this:

s = ssh.Connection(host = 'example.com', username = 'warrior', password = 'lennalenna')

Of course, Python also allows you to use the order to specify the arguments, so the last example can be written as:

s = ssh.Connection('example.com', 'warrior', password = 'lennalenna')

Operations

Once you have set up the connection, there are three methods you can use. Firstly, to send a file from the local machine, you can use put:

s.put('hello.txt')

The above example copies a file called hello.txt from the current local working directory to the remote server. We can also be more explicit if we want:

s.put('/home/warrior/hello.txt', '/home/zombie/textfiles/report.txt')

So the above example copies /home/warrior/hello.txt on the local server to /home/zombie/textfiles/report.txt on the remote server.

The second operation works in a similar way but in reverse:

s.get('hello.txt')

get takes the file from the remote server to the local server, again we can be more explicit if we want:

s.get('/var/log/strange.log', '/home/warrior/serverlog.txt')

The above example copies the strange.log from the server and saves it as serverlog.txt.

The last operation is execute, this executes a command on the remote server:

s.execute('ls -l')

This returns the output as a Python list.

Closing the connection

You can do as many operations you like while the connection is open, but when you are finished, you need to close the connection between the local and remote machines. You do this with the close method:

s.close()

There we go, that is all I needed to do with SSH. Please do let me know using the comments below if you have any problems using it.

If you import my module in your program and later find that you need more power or flexibility, you should be able to swap it out for the full paramiko with a minimum of fuss.

<someone> What are you doing in front of your computer all day?
<me> Hmmmmm, I'm working ... kind of.
<someone> All the time?
<me> Not all the time, but well, probably most of it.
<someone> Aren't you chatting or stuff like that?
<me> Yep, but that's not the type of chatting you're used to I guess.
<someone> What are you working on?

<me> Well, there's this Open Source project, called foo I am helping a little bit here and there.
<someone> What is Open Source?
<me> Hmmmm, well ... 
[skipping stuff about available source code, licenses, the M$ example of closed sources and so forth].
<someone> Aaaaaha (I haven't really understood 75% of what you've just said but).
<someone> Are you or the others getting paid for what you do?
<me> Actually, nope, there are exceptions of course.
<me> However, chances are that someone maybe donates a few bucks.
<someone> That doesn't make any sense at all, why are you doing this?

Fun

People

Reward

In your scripts or applications, you might need to copy a file from one server to another. One way to do this is to use SFTP, the secure file transfer program, which uses an encrypted SSH (Secure Shell) transport which in turns runs over TCP/IP.

One of the Python implementations of SSH is called Paramiko (available in package managers as paramiko or python-paramiko).

Paramiko is extremely comprehensive so you can get as complicated as you like, but for me, I just want to be able to copy files from a known remotepath to a known localpath and back again.

In this post I explain how to do this using Paramiko directly, in the next-post, I look at another approach.

So we start by importing the module, and specifying the log file:

import paramiko
paramiko.util.log_to_file('/tmp/paramiko.log')

We open an SSH transport:

host = "example.com"
port = 22
transport = paramiko.Transport((host, port))

Next we want to authenticate. We can do this with a password:

password = "example101"
username = "warrior"
transport.connect(username = username, password = password)

Another way is to use an SSH key:

import os
privatekeyfile = os.path.expanduser('~/.ssh/id_rsa')
mykey = paramiko.RSAKey.from_private_key_file(privatekeyfile)
username = 'warrior'
transport.connect(username = username, pkey = mykey)

Now we can start the SFTP client:

sftp = paramiko.SFTPClient.from_transport(transport)

Now lets pull a file across from the remote to the local system:

filepath = '/home/zeth/lenna.jpg'
localpath = '/home/zeth/lenna.jpg'
sftp.get(filepath, localpath)

Now lets go the other way:

filepath = '/home/zeth/lenna.jpg'
localpath = '/home/zeth/lenna.jpg'
sftp.put(filepath, localpath)

Lastly, we need to close the SFTP connection and the transport:

sftp.close()
transport.close()

In my humble opinion, one should not have to write so many lines or care about the SSH protocol just to send a file from a to b. In the next-post, I will share my own higher level API that runs on top of Paramiko.

I've been very busy the past week, mostly just for the fact that I worked eight days straight. It might have been good money, but tomorrow is a well-earned break. In these past eight days, I fell behind in some of the reviews I've been writing.

I meant to post a review of the OCZ Reaper HPC DDR2 RAM I used in my reviews of the 780G motherboard and Radeon HD3870 Toxic, but fell behind because of all the extra hours spent at work. There're several more reviews to follow the review of this RAM, but my main concern right now is the RAM.

BIOSLEVEL has several fantastic reviews coming up, but what I'm really excited about is a home theater series of articles I'm trying to plan out utilizing MythTV. We have one machine that's able to act as a MythTV box itself, as well as a MythTV server so other units can connect to it. This'll be a great option for some units such as the Asus barebones I recently reviewed for BIOSLEVEL

On the bright side of my time issues, I did manage to get a little done on a new design for this site, as well as business cards for BIOSLEVEL. Once both are completed, I'll post the final designs. Or, that is, change the design of the side and post an entry about the business cards.

I listen to MP3s in the car and it's annoying when the volume isn't normalized. I can't be fumbling around with the tiny buttons on my MP3 player to adjust the volume while I'm driving. I found mp3gain and used it on a bunch of files and it appears to have worked.

If anyone knows of a better program for normalizing volume of lots and lots of MP3s, post now or forever hold your peace.

Here’s my perspective on it. We all have ideas, some good and some bad. Now it’s understandable that people who have invested themselves into a bad idea, especially if they thought it was good, are reluctant to walk away from it. It’s painful to have to realize that. But the flip side is that we have to maintain the myth of Santa Claus because, well, so many kids believe in him that we can’t let them down. Bad ideas deserve to die for the good of everyone.

The first thing a good idea must have is a real problem to solve. OpenID does very well here. The point of OpenID is to solve our common problem of the internet age: many websites, many accounts, many usernames and passwords. This is probably why OpenID still appears to some people as being a good idea.

Here’s how they do it. Instead of keeping track of your accounts on all the sites you’re a member of, just let one site keep all your account records (sound ominous yet? it did to me). Now, whenever you want to login to one of your sites, instead of using your username/password for that site, you use your OpenID login, which looks like this: http://username.myid.net. This url is effectively your OpenID provider, ie. the site you use to keep track of all your accounts. So now the site you’re logging into sends you to your provider, where you login with a username/password belonging to the account on the provider site, and that logs you into the site you were visiting. So in other words, your account on the provider is the gatekeeper to all your accounts. Sounds simple, right?

I remember when I first heard about this idea years ago. The first concern I had was that in order for this to work, I need a provider to keep track of all my accounts. So I asked myself the question: whom do I trust do this for me? The answer came back: myself. I don’t know about you, but the idea of some third party storing all my logins doesn’t make me feel warmy and cuddly. As it happens, the open in OpenID means you can choose any provider you want, including yourself. You just set up some php scritps and voila, you can use http://mysite.com as your provider. So basically, instead of storing your accounts in some “account manager” program on your computer, you do the same thing on your server. This is where the concept of OpenID died for me. I don’t want to have to depend on my own OpenID provider to work in order to use other sites. I don’t want to add a dependency on my ability to login to some other site contingent on the assumption that my own site is available and working properly at all times (which it isn’t, I have a little downtime like everyone else).

If you don’t want the hassle of being your own provider, you can pick a provider from a list. This is not an attractive fallback option, because now your account on the provider is your key to all your other accounts. If I have an account on some site and I forget my credentials, big deal, I only lose that one account. But if I lose my credentials on the provider, I lose everything.

In theory, OpenID tries to improve your overall security. The hassle of keeping track of accounts is known to us all, and we get around the problem by reusing the same (or similar) credentials on a lot of sites. This is obviously bad for security, because if someone gets your password to one site, they can access all your other accounts that use this password. So security people will always recommend that you use distinct credentials for every account. Suppose you do this, and you use OpenID to alleviate record keeping. Now, OpenID actually works against you. Your account on the OpenID provider is the key to everything. With a different password on every site, you’re that much less likely to remember what it was, therefore your account on the provider is proportionally more valuable.

There is a strange irony at play here. Supposedly, the more accounts you manage with OpenID the more useful it is. But on the other hand, the more accounts you manage with it, the more you depend on it, and the more you make it the one gateway to all your online identities for a potential attacker or for abuse by a dishonest or incompetent provider.

Most importantly, however, OpenID’s solution to the login problem isn’t a very clever solution at all. Typing http://username.myid.net is not a big improvement over a username/password form. My browser already gives me the option to login without typing anything.

Those are my reasons why OpenID is a bad idea and should have died years ago. If you want more, Stefan Brands has an exhaustive laundry list of problems with OpenID.

Something is very wrong here. Right after starting a KDE session everything looks normal.

But after running for a day we have a different story. I’m assuming this isn’t the expected behavior (if so I didn’t expect it).

This time I specifically took a screenshot to prove it, but I’ve seen it eat up as much as 1.3gb of my memory, which is rather unnerving.

kwin-kde4        4:4.0.4-0ubuntu1

Bug report.

Emacs has a, well, "unique" undo system. It only has undo, no redo. When you undo something, the act of undoing is added as itself onto a stack of undo actions. When you've un-done enough things, you do "something, like move the cursor, and that breaks the chain. From there if you undo again, you will traverse back over the undo actions you just did.

This is supposedly powerful. It does help with the following situation:

1. Type something.
2. Type something #2.
3. Type something #3.
4. Undo undo undo.
5. Type something #4.

In most programs once you reach step 4, you can redo to get back to the text you just undid But once you reach step 5, the first three things you typed are lost forever. You've gone back in time and changed history, eradicating the old future and replacing it with a new one. You can never get back to the old future. Emacs undo, on the other hand, where undo actions are just like any other actions and pushed onto a stack of actions, does let you undo back first three things you typed.

However in practice this doesn't work so well. This site has a nice quote:

“By [undoing] repeatedly, you can gradually work your way back to a point before your mistake. This is convenient if you’ve made a mistake four or five commands back. It is marginally useful if you’ve made a mistake twenty or thirty characters back. And it is completely useless if your mistake is ancient history.” - Learning GNU Emacs (page 42)

The problem being, supposing you undo 20 times, and break the chain (by moving the cursor for example), if you then decide to undo one step FURTHER back, you have to undo all 20 of your previous undos, undo 20 more times, then undo once more. Eventually you end up feeling like you're going up and down a roller coaster of undos.

If you hate this, which you probably do, you could use redo mode, which gimps up Emacs undo/redo to be like any other program's, i.e. you get the same behavior as Microsoft Notepad. (Although when I tried it, it was buggy as heck, failing to undo my actions properly, mangling text from different lines together and whatnot.)

Vim's undo system on the other hand is far better and equally powerful. You have a standard undo / redo option via u and CTRL-R. You also have a second completely different way to undo: you can "go back in time". In the above example, Vim will create two undo "branches" and you can jump from one to the other even if you undo and "break the chain" by typing something new.

Doing :undol lists the branches, in a somewhat confusing format. But you can just pound g- and g+ to go to older / newer text states, or use :earlier with a human-readable time (say, 10s or 5m) and it will take you to that point. These will get you all the power of Emacs' undo stack, with none of the pain or confusion. See also :h undo-two-ways.

This is one of many instances where Vim wins, hands-down. Vim's undo system isn't as reprogrammable as Emacs, but it's so powerful and so perfectly what you'd want that it doesn't matter. This is beautifully typical of Vim. I don't have a year to figure out all the nooks and crannies and edge cases and idiosyncrasies of Emacs undo system, let alone the time it'd take to write a custom, crusty elisp script to buggily re-implement it.

Being an "extensible text editor" doesn't help much when such basic functionality is so broken. Unless you want to play your undo history back like a movie, in rainbow colors, which I don't. I want undo/redo that works.

I have a friend and fellow member of the Python West Midlands group. Whenever, someone mentions Django, he asks the person "but is it stable?". This has been repeated so much that is has become a local in-joke. However, lets take the question seriously.

To explore this further, we need to ask what does stable mean? I.e. can we replace the word "stable" with something else to provide some more meaningful questions:

• Can Django handle traffic loads?
• Is Django actively maintained, i.e. are bugs being fixed?
• Will the Django API evolve in the most backwards compatible way possible?

Lets take these one at a time.

Traffic loads

Django's frequently-asked-questions says:

Is Django stable?

Yes. World Online has been using Django for more than three years. Sites built on Django have weathered traffic spikes of over one million hits an hour and a number of Slashdottings. Yes, it's quite stable.

The first sentence is a testimony, useful but not a direct answer. In the second sentence, 'stable' is used as in 'strong table', i.e. Django can handle a heavy load, (i.e traffic rather than physical objects).

It goes on to explain that Django has a "shared-nothing" approach, i.e. you can throw more servers directly at whatever bottleneck you have. If the database is the database, then you can add more hardware to the databases, if it is images the are the problem, you can add more hardware to the media servers, and so on.

Is Django maintained?

The next question is whether Django is actively maintained. One simplistic measure is to look at the bug database and see what is going on. In what follows I use "ticket" in the broadest sense, i.e. not just a confirmed code error, but also enhancement requests, invalid bugs and so on.

At time of writing, Django has 1092 open tickets, out of which, 311 are new and unreviewed, I would guess that half of these are valid problems, and half are not.

Meaning the other 781 open tickets have reviewed by someone at least once. Some have been triaged and are waiting to be worked on, some are already being worked on, some will have been closed wrongly and reopened.

In the last three years, 6047 Django tickets have been closed, we can break these down further:

A ticket being fixed is very useful, but a ticket being found to be not a problem or not Django's problem is still useful information, marginally useful perhaps, but still useful if you have that issue.

So Django is three years old, which is pretty new. In that time, they have closed 85% of tickets, while 10.6% of tickets are open but have been read, 4.4% are open and have never been read.

This seems competitive with similar open-source web frameworks:

The 'years' column represents how far the ticket tracker data goes back for, not necessarily the age of the project. There may also be sampling errors caused by differences in the ticket tracker software, or a project might have had a clear-out of closed tickets.

On the whole, it is all impressive stuff, all six open-source projects seem to be on top of things. One nice thing about Pylons is that, at the time of writing, it appears that all of the open tickets have been reviewed to some extent. Some other projects such as Django would benefit from more a few more triagers to review new tickets.

API

This is perhaps what my friend meant, i.e. if one makes a web application using Django in 2008, how much pain will it be for it to still work in 2013?

There is of course a balance to be struck between backwards compatibility on the one hand, and keeping the framework modern enough for meet the needs of today's web applications. It is a difficult balance.

As Joel Spolsky points out in How-Microsoft-Lost-the-API-War, if you change your API such that users of it have to learn new things or change software in any significant way, the risk is that the users of the API will instead decide this moment to jump to the next big thing.

On the other side, changing too slow is also a risk. Apart from people like me when I am feeling retro, does any one really create web applications of any complexity using only the CGI support in the Python standard library? The API has not changed much in the last half-decade which is good, but the standard Python CGI is lacking in any pre-built features so you have to do all the repetitive boilerplate yourself. Also CGI generally has no persistence or caching meaning that it is far more processor intensive.

I don't want to be mean, but all the cool things that people are actually using to make web applications in 2008, such as SQLAlchemy, Django and Pylons are outside the standard library and have very little chance of merging with the standard library. I am not going to mention Python Server Pages, (oh I did - d'oh).

So the balance between backwards compatibility and providing modern features that people want is the life-or-death question for a larger toolkit such as a web framework.

Django provide their answer in a webpage called API-stability, in this document, they explain what seems a reasonable compromise between backwards compatibility, and changes that are required to keep the framework both modern and secure.

Of course, the document is mere policy/propaganda and the real issue is whether they stick to it. However, Django is free software/open source and it is being used by a large number of people. If the Django developers change the API unnecessarily, people will vote with their feet and not upgrade and/or fork the API.

Django Development

So is Django stable? Well given what we looked at above, we can at least say that it does not seem any less stable than any other similar toolkit.

The philosophy of a traditional software application, often goes like this: there is a cycle, starting with the development window, followed by a code freeze, followed by stabilisation, followed by a release, followed by a new cycle.

The current fashion in the Django community is to develop sites using the SVN version of Django. This philosophy is that the mainline branch should be usable at all times, and the latest SVN revision is likely to be less buggy and more secure than previous revisions.

This approach is somewhat all or nothing; you decide yourself to become a web developer using Django and so commit yourself with keeping up with the state-of-the-art. Perhaps this is the only way for a toolkit of such complexity. This investment is perhaps less of an issue if Django becomes the mainstream way to make a web application in Python.

The Django developers do however plan on an eventual 1.0 release, their plans are nicely summarised on a wiki page called VersionOneFeatures. At Version 1.0, the toolkit will (in theory) have a fixed point. After that they plan to do the Pythonic thing of not breaking the API in one step. So if they want to introduce an incompatible change that requires code changes to the user's web application, they will provide a warning in the next release, and then make the incompatible change in the release after.

However, I imagine most people will continue tracking SVN. Since a person needs a certain level of technical skills to use Django at all, then they probably have enough skill to handle some minor API changes.

Stability is a process. Complex software is never finished, it just runs of money or becomes obsolete.

Your turn. What do you think? I would love to know your opinions?

Say you're at a party and the only internet is a wireless router and for whatever reason, no one can plug into it. Wireless internet only. You with your fancy laptop are sitting pretty and this is just fine. They your friend shows up lugging his clunky old desktop that only has an ethernet port for internet connectivity. Is he out of luck? Turns out not, because you an come to the rescue!

It's really easy, especially with Ubuntu.

To start with, you need to be a router, so you need firewall software that can do NAT (network address translation). This is part kernel side (NAT and iptables options enabled and modules loaded) and part user space side, in the form of the program 'iptables', so make sure it is installed, which it is by default on Ubuntu (I think).

Now all you really need to do is add two routing rules, one says anything coming on the ethernet port should go through the NAT procedure, which basically means it's IP headers are tweaked to make it look like they originated from your computer and then you send them along to the internet. The second rule helps facilitate this (I'm a little less sure what it does, but it's needed).

In this case we are assuming the interface eth0 is the wired network and eth1 is the wireless. Change as required.

iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE
iptables --append FORWARD --in-interface eth0 -j ACCEPT

Next you just need to tell the kernel port forwarding should be turned on, and you can do this through the wonderful /proc filesystem.

echo 1  > /proc/sys/net/ipv4/ip_forward

Now you're pretty much ready to go. Connect to the wireless, presumably though NetworkManager or your wireless toll of choice. Then enable the wired network manually.

ifconfig eth0 up 192.168.1.1

This turns on eth0 with a local network address of 192.168.1.1. Now plug your friend's computer into the ehternet port with a crossover ethernet cable or into a hub and then the hub into you with regular ethernet cable and have them manually pick an address on 192.168.1.* (or whatever local network you chose, it doesn't matter) and set you (192.168.1.1) as the gateway router.

If this is a little much for them or they are running an OS that makes this non trivial, than its really another easy step for you to set up a DHCP server and do all the configuration for them :).

So install dhcpd, on Ubuntu it's 'dhcp3-server', on Gentoo I think it's just 'dhcpd'.

Now we have to configure it. We have to tell it the gateway router, which is us (192.168.1.1), the nameservers (the servers in /etc/resolv.conf) and the pool of IPs to use and what interface/network to listen on.

Open the config file, on Ubuntu '/etc/dhcp3dhcpd.conf'.

The relevant parts are as follows

...
# servers in /etc/resolv.conf
option domain-name-servers 192.168.0.1;

...

# the local network you created
subnet 192.168.1.0 netmask 255.255.255.0 {
        #IPs free to assign
        range 192.168.1.100 192.168.1.200;
        #your computer, the router
        option routers 192.168.1.1;
}

And that's it. (Re)Start the server

/etc/init.d/dhcp3-server restart

And you are now serving all the information your friend's computer will need to automatically connect properly.

They should now be online once they restart their internet connection.

One annoying thing about Ubuntu vs Gentoo is that on Ubuntu, the init system is a bit more kludgy and old fashioned. Any server software installed is automatically configured to start at boot time, forever, which in this case isn't what you want. You only want the dhcpd server to run very rarely, at parties, the rest of the time it's a waste. So we need to turn it's auto starting off. Apparently the /ubuntu init system barely supports this, we have to force it.

update-rc.d -f dhcp3-server remove

Now just turn it on when you need with its init.d file.

Since I moved my laptop to the new OpenRC init framework, my GPRS connection stopped working. At first I didn’t know what needed to be changed, but after having a careful look at /usr/share/doc/openrc/net.example and adjusting the proposed ppp chat script, I got it up and running again. Here is my configuration:

### GPRS ###

config_ppp0=( “ppp” )

link_ppp0=”/dev/rfcomm0″

pppd_ppp0=(
“noauth” # Do not require the peer to authenticate itself
“debug”
“local” # Ignore carrier detect signal from the modem

“defaultroute” # Make this PPP interface the default route
“usepeerdns” # Use the DNS settings provided by PPP

“lcp-echo-interval 15″ # Send a LCP echo every 15 seconds
“lcp-echo-failure 3″ # Make peer dead after 3 consective
# echo-requests

“lock” # Lock serial port
“115200″ # Set the serial port baud rate
“crtscts” # Enable hardware flow control
)

chat_ppp0=”
ABORT BUSY
ABORT ERROR
ABORT ‘NO ANSWER’
ABORT ‘NO CARRIER’
ABORT ‘NO DIALTONE’
ABORT ‘Invalid Login’
ABORT ‘Login incorrect’
” AT
TIMEOUT 5
OK ‘ATH’
OK ‘ATE1′
OK ‘AT+CGDCONT=1,\”IP\”,\”cmnet\”‘
OK ‘ATD*99#’
TIMEOUT 60
CONNECT ”
TIMEOUT 5
~– ”
“

At work, we've setup the Netlog Developer Pages

It is the place where you can/will find all information around our OpenSocial implementation, our own API, skin development, sample code and so on.
We've also launched a group where you can communicate with fellow developers and Netlog employees.
The page also features a blog where you can follow what is going on in the Netlog Tech team.

read more

Extensions are cool

Extension frameworks are a good way to add new functionality to large applications that are messy to alter directly, they also help to quickly add functionality now, without having to wait six months for the next release.

The whole fun of extensions is that you can make your own and download random ones from the Internet, try them out for a bit, remove the ones you don't like, share the ones you do.

This of course implies two things. Firstly, that the extension interface is well thought out so that a badly written extension does not crash or unexpectedly interfere with the main application. Secondly, that the user who installs the application is adept enough to know what they are doing.

The killer feature of Firefox has been its extension framework, having hundreds or even thousands of useful extensions is what has enabled Firefox to break into the IE-dominated browser market where so many have failed.

All your extensions belong to us

Firefox 3 has changed many things compared to previous versions. One unexpected change is that the extension framework has been locked down.

I have mixed feelings about this. I understand there is a balance between on the one hand, fun and spontaneity, and on the other hand, security and protecting clueless people from themselves. However, for me, I hate software designed as a jail for idiots. That is why I refuse to use Windows for anything beyond testing that web applications work on it.

Firefox 3's extensions framework has a new DRM-like security barrier. You have to either submit your extension to be vetted and hosted by Mozilla, or you must use SSL, or use cryptographic keys.

I am all in favour of cryptography (as long as it is open for everyone to play), but I would be worried if this implementation makes it harder for people to write and share updates.

Computer says no

I tried to install an extension the old fashion way, by going to the author's homepage and clicking on link to install the extension.

Firstly, there a warning popped up, the same warning that was also in Firefox 2:

So I clicked "Allow" and then reclicked the install link.

Then, like a naughty child, we have to wait 4 seconds as a cooling off period, before we can click "Install".

Thirdly, even though we clicked "Allow", then were put into time-out like a child, then clicked "Install", it flatly refused to do what I had told it to do:

'Secure' here being defined as "approved by Mozilla", very few Firefox extensions are secure in the formal sense of 'trusted'.

I am root

I know Firefox are trying to keep us safe, but I have to admit that the interface here gets on my nerves somewhat. There are "Allow" and "Install" buttons, I press them, but Firefox changes its mind and does not do what the button says.

Fortunately, in Firefox, the extension censorship can be overridden in the about:config settings dialog. So I went to Firefox 3's about:config page, and guess what? Yes you guessed it, they have added another new confirmation screen!

Oh well, all's well that ends well. I am sure some of you will have strong views either way on this. Let me know!

I have used Ekiga quite a bit. It is one of the main free software voice over IP clients. It is often installed by default on many GNOME-based systems such as many free software distributions, and it is also available on Solaris.

It also now has a Windows port, so I thought I would try it out. Giving any remaining Windows-using relatives Ekiga means they can chat to you online without you having to install proprietary phone clients that do strange things on your network.

To start with, you need a SIP username, I got a free SIP username from Ekiga's online-registration, but you can get one from any SIP provider, or you can be your own provider by running your own SIP server such as Asterisk.

To start with, lets just use Ekiga's free usernames.

So once you have a SIP username, we want to download Ekiga. the Windows binary is available from Ekiga's Windows-Users page.

Download the exe and click on it. This will bring up a little box asking you for your language. My first language, English, was the default so I went with that.

Next comes the Ekiga Setup Wizard:

Press next twice and you get this:

Press finish. I did this on Windows XP, which brought up a warning me that Ekiga is attempting to connect the Internet. Being a program to chat over the Internet, I pressed "Unblock":

Next is the First Time Configuration Assistant.

It will ask you for your SIP username and password (i.e. the username we created at the beginning of this article), and it will try to detect your microphone, speakers and webcam (if you have one).

Press "Forward" a lot and read through each of the screens. when you are done it will summarise your choices:

Press "Apply" if you are happy, or press "Back" to change them.

So now hopefully you are done with all the hard work. You should see the main Ekiga interface like this:

The first icon on the right allows you to open a text chat with the person you are talking to.

So far, I only really use Ekiga to call my friends over the Internet, I have never phoned a landline, therefore I turned the numberpad off, you can do this by clicking the second item on the left, or by going to the "View" menu, and choosing "View Mode" then "Videophone".

Typing usernames into the address bar is a bit dull, so pressing the third icon on the left of the interface brings up the address book. If you add your friends to the address book then you can click on them rather than having to remember their SIP username.

Ekiga has many more features, but you can easily discover most of them yourself.

Now you probably want to test it. Put sip:500@ekiga.net in the address bar and press enter. This will call the Ekiga 500 echo service. It is a robot who will echo back whatever you tell it, this way you can tell whether your connection, microphone and speakers are working properly.

Happy chatting!

Today I was trying to upload a lot of mail (something like 160000 mails stored in a deeply nested folder structure of about 13000 folders) to an IMAP server. Those mails were converted from the Eudora mailbox format to a more sane Eudora mailbox format using “Eudora rescue”, and then imported into Thunderbird’s “Local folders”. From there, so we thought, it would only be a matter of minutes to put those mails onto the newly setup dovecot IMAP server, with one drag-and-drop action.

But…

The upload horribly failed after the 3rd folder or so, with no error message whatsoever. No matter what I tried, it would just fail silently. The debug logging (see Debugging/Thunderbird article in the Dovecot wiki) didn’t help, and neither did dovecot’s log on the server. The problem seems to be connected with creating folders on the server somehow - because uploading a big amount (400 for a small test) mails within one folder wasn’t a problem. I couldn’t find out if Thunderbird or dovecot is to blame here