therning.org/ magnus

I’ve recently found del.icio.us and I’m reading their RSS feed every now and then. Today I stumbled on this gem. Basically Google is not only a search engine, it’s also a

• Calculator (2 * 2 + 2, 45% of 60)
• List of definitions (define:google)
• Unit converter (85 kg in lbs)
• and much more…

Google is amazingly useful!

I installed the Ubuntu build of 2.6.11 yesterday and noticed that my touchpad didn’t work properly. It felt sluggish and tapping it didn’t work at all. A bit of googling turned up this and this.

I didn’t bother with the Synaptics driver for X.org, mostly since I wasn’t sure the suggested kernel patches are in the Ubuntu kernel. Also, I can live with 2.6.10 until Breezy Badger… with the focus on laptops I’ve seen on the Ubuntu dev-list I can’t imagine they’d let such an obvious thing as a non-functioning touchpad slip through.

As I mentioned here I’ve been having problems with my Windows CA. I’ve now managed to get an OpenSSL CA up and running and I’m able to get my Windows box to accept the certs/keys. This is how I did it.

First make sure all tools are available. You’ll need openssl, make, and some way of getting the generated certs/keys from your CA machine to your server, I use SSH for that.

I used this site as inspiration. I changed the policy to the more accepting policy_anything and I changed the description of my CA in root_ca_distinguished_name. After that I ran make init to create the CA cert and key.

$ make init
Generating a 2048 bit RSA private key
........+++
.................................+++
writing new private key to './private/ca-key.pem'
-----

Quite a few new directories and files have been created:

$ tree
.
|-- Makefile
|-- ca-cert.pem
|-- crl
|-- index
|-- newcerts
|-- openssl.cnf
|-- private
|   `-- ca-key.pem
`-- serial

3 directories, 6 files

We’ll convert the CA’s certificate (ca-cert.pem) to a format that Windows can use right away, we’ll need it later:

$ openssl x509 -in ca-cert.pem -outform der -out ca-cert.der

Now it’s time to create a certificate signing request (CSR). To impose some order I created a dir to keep my client-related stuff in, $ mkdir -p client/svc01. After changing into the client dir I create a CSR:

$ openssl req -newkey rsa:2048 -keyout svc01_priv.pem -keyform pem \
    -out svc01.csr -outform pem

A few questions are asked about the cert/key (remember that the common name should be the FQDN of the server), and a password for the private key is required (at least four characters long). The CSR is saved to svc01.csr. Now change back to the CA top directory and copy the CSR here. Then run make sign to issue the certificate. The cert ends up in svc01.cert, move it down to the client directory ($ mv svc01.cert client/svc01/svc01_cert.pem, since I’m using the CA to issue certificates for Windows servers I like to make the file format explicit).

Now that we have the signed certificate, svc01_cert.pem, and the private key, svc01_priv.pem, we need to package them both in a PKCS12 file so that Windows can use them:

$ openssl pkcs12 -export -inkey svc01_priv.pem -in svc01_cert.pem \
    -out svc01_CertNKey_p12.cer

You’ll have to enter the password to unlock the private key, you’ll also have to enter the password to be used for exporting the private key out of the resulting file later on (I like leaving it empty). Copy the file to the Windows machine and change its suffix to .pfx, now you should be able to import the key and cert. In order to use the key you’ll also have to install your CA’s cert (ca-cert.der).

In this post I described my udev setup. The one drawback with using udev that way is that I need to cll pmount manually everytime. Yesterday I stumbled across some posts on the the Ubuntu mailing list and I’ve started liking Gnome’s Volume Manager a little better since.

Using e2label I set the label on my ext2 partition. This causes pmount to mount the partition using that name.

Then of course I didn’t want the device itself (/dev/sda in most cases) to be mounted. As an experiment I modified my udev rule to only apply to the device:

BUS="usb", SYSFS{serial}="070B000514B09F0", KERNEL="sd?", NAME="%k", \
  SYMLINK="usbstick_priv"

As expected having udev add the link somehow prevents pmount from mounting the device.

Now all that is left is to set the label of the VFAT partition on my USB stick.

Today I ran into another case where Windows just isn’t very friendly. I’ve been using a Windows box as a CA for a while now. Mostly because it was so easy to set up, I was off in just minutes granting certificates to my hearts content. Great! Or so I thought.

Today I wanted to look at the traffic comming from a server I have installed. I’m using an SSL cert signed with my own CA. The problem is that I need to get the secret key out of Windows’ tight grip. I’m admitting, this is not something that should be easy, but the question is where to put the hurdles. using the Certificates Snap-in in MMC I can’t export the secret key. My next step was of course to check if I couldn’t get my CA to create a new cert, where the key was exportable. Oh, no! That shouldn’t be allowed when the cert is for a server! The tick box is taunting me with its disabled presence! Bloody hell!

Well, I’ve always thought it might be a good idea to explore the dark side–OpenSSL. Here’s my chance. I get to use Linux while doing it as well, that’s always a plus. Just pray that I can get the results back onto my Windows server in the end!

I guess it’s true, Windows my be user friendly, but it shure as hell isn’t admin/developer freindly!

I just discovered FreeNX today

I’ve been using VNC for a while at work now, and mostly I’ve been happy with it. Being on a fast internal network with the server literally at my feet hasn’t made me swear at the lack of speed. The only thing that has irritated me a little is that my VNC sessions aren’t properly secured. I don’t have anything to hide really, but working with security it just didn’t feel right. Sure, I could, and I did for a while, secure it using SSH, but since the client is a Windows machine it makes it all a bit clunky. Requiring a PuTTY instance with port forwarding to be running is plain ugly. An encrypted connection really should be built into VNC by now. So, I decided to take FreeNX for a ride.

Unfortunately FreeNX isn’t in Ubuntu Hoary, however there is a page in the Ubuntu Forum, which is a bit outdated–it covers Warty mostly. Some of the comments in the forum did point me to the Backports project. I don’t really like the Backports (I managed to screw my system up a bit a while ago) but they do seem to have grown up a bit by now. Anyway, I only added the repos to my sources.list long enough to install the packages I needed.

Installation was a breeze. I chose to use custom keys, sorting out the client-side problems created by that turned out to be simple as well. No extra tinkering with the config files seemed necessary.

For the Windows client I am using NoMachine‘s Windows client. In order to use it with my server I needed to copy the public key (on the server: /var/lib/nxserver/home/.ssh/client.id_dsa.key) to the share dir on the client side (you’ll find it’s a subdir to the install dir of the client software). That’s it, password-less remoting of my Linux desktop with the security of SSH. Brilliant.

The author of DVD Decrypt, Lightning UK, has received a letter ordering him to cease development/support/etc relating to DVD Decrypt (the announcement). A “certain company” is behind it. People are guessing that it’s Sony, which would make sense, I guess. Anyway, I’m happy I’m out of the consumer electronics market where daft content providers are ruling at the moment. Unfortunately I’ve moved to a country where circumventing copy protection isn’t allowed (the same country where Lightning UK lives).

This is a very short proxy written in Python using Twisted 1.3. It forwards port 1080 to localhost:80.

from twisted.internet import reactor
from twisted.protocols import portforward

def server_dataReceived(self, data):
    print 'Server received data:', data
    portforward.Proxy.dataReceived(self, data)
portforward.ProxyServer.dataReceived = server_dataReceived

def client_dataReceived(self, data):
    print 'Client received data:', data
    portforward.Proxy.dataReceived(self, data)
portforward.ProxyClient.dataReceived = client_dataReceived

reactor.listenTCP(1080, portforward.ProxyFactory('localhost', 80))
reactor.run()

Short and sweet, I think.

I was looking around for a way to get a Python SOAP client to access a web service hosted in such a way that NTLM authentication was needed. Lacking any indication of built in support in SOAPpy to handle this I turned to trusted old Google. I found this, a small NTLM HTTP authentication proxy written in Python.

Configuration was a breeze, After putting in the domain (NT_DOMAIN) and the user (USER), skipping password (PASSWORD) since it can be done interactively it didn’t quite work. I had to tweak the values for LM_PART, NT_PART, and NTLM_FLAGS, setting them to 1, 1, and 07820000 respecitvely.

I performed my testing downloading the WSDL file using wget.

Well. It looks like I can use the XMLRPC to post to my WordPress blog. Nice! Information on setting it up is here.