Installing Wine 1.2 in Ubuntu 9.10 (Karmic)

There is a known bug when installing Wine in Ubuntu 9.10 (Karmic), documented in this bug report.  From comments I've seen it affects upgraded installations of Ubuntu rather than fresh installations.  The log shows errors similar to this:


error: "sys.kernel.maps_protect" is an unknown key
error: "net.ipv4.ip_always_defrag" is an unknown key


Comment #11 on the above bug report solved the problem for me.  These are the steps I took:

• Take a backup of the file /etc/sysctl.conf
• Edit /etc/sysctl.conf (as root) and comment out the following lines by putting # in front of them (note that they are not all together in the file):


kernel.maps_protect = 1
net.ipv4.ip_always_defrag = 1
sys.kernel.maps_protect = 1


Then install Wine using your preferred method.  Once complete, uncomment the lines again and save.

I used to have Wine installed when this machine was running Jaunty but somehow Wine completely borked the upgrade from Jaunty to Karmic, necessitating a complete restore and removal of Wine.  I guess this was something to do with it.

Using Tomcat 6 on Xubuntu

Currently I'm doing some Java education.  In order to learn and understand some of the mechanics, I'm using a plain text editor instead of a sophisticated IDE and compiling on the command line.

I'm running in a VM, so I'm using Tomcat on Xubuntu (because it's reasonably lightweight) and Geany as my text editor.  This isn't as plain as using Mousepad (the default text editor in Xubuntu) but I'm only using it for syntax highlighting and outlining at the moment.  Once the compiling is done then testing is done running java manually from the command line and deployment is done by copying files manually into the Tomcat webapps directory.

It's all a bit different from my usual working environment, which is IBM Rational Application Developer (based on Eclipse) - auto-completing class names, automatically sorting out my imports, creating WAR files for me, and deploying to WebSphere Portal.  It took me a little while to figure out where things need to be deployed, and I'm not sure I'd ever run a Java program from the command line before!

So here's a reminder to myself:

• web apps are deployed in /var/lib/tomcat6/webapps
• compiling is done from the root development directory, like this:

~/webapps/MyWebApp$ javac -classpath classes:. -d classes src/com/example/model/TestModel.java

where the classpath is a colon-separated list of the parent directories of classes (i.e. "classes" has the directory structure com/example/etc underneath it) and the -d switch controls where the compiled output goes.

• running a Java program (say, a test harness): 

~/webapps/MyWebApp$ java -cp src:classes com.example.model.test.TestModel param

where, again, the classpath (-cp) is the parent directory of necessary directory structures, and the class to be run is specified by its fully qualified name, not its path.

• If you use the Tomcat web application manager to deploy a WAR file via the UI, the context root for the application is <war-name>/<root-mapping>. So if the mapping in web.xml is, say "/myservlet" and you WAR is called MyServlet.war, the correct place for the app is /MyServlet/myservlet. (This caught me out and cost me about an hour one time ...)

It might all seem simple stuff to you but when you're used to the tool doing it for you, it's easy to forget.  Took me a couple of goes to get it right!

Using Squeezebox Server remotely

My favourite gadget that I bought last year was my Squeezebox Duet.  But one of the best things about the whole Squeezebox package is actually the software.  The server is open source, which means I could play with it for a while before I splashed some cash on the hardware.  It's what won me over.

What's also won me over is this: with the server running at home, and a little set up, I can play music from my collection from wherever I am (with my PC and a network connection).  None of this is difficult (if you know how to tunnel TCP ports over SSH, you can probably go somewhere else now) but I wanted to document it so I can repeat it if/when necessary.

These instructions were originally for an Ubuntu 9.04 server, already running Squeezebox Server. I've now also used them with on a Pogoplug running Debian Squeeze. The client could be any Linux as it's all command line; I've used with Ubuntu 9.10, 10.04 and 11.04.  YMMV.  Etc.

Firstly, I set up a key on the client that to be used to authenticate with the server.  The Ubuntu documentation has a good guide, including an explanation of why a pass phrase is a good idea.  The steps I used were:

• Open a terminal
• Enter ssh-keygen -f ~/.ssh/id_rsa -t rsa -b 4096
• Enter your pass phrase twice.

Then I used a USB key to copy the public key (id_rsa.pub) to the server.
Next, I prepared the server:

1. Installed the SSH server by installing the openssh-server package.

2. Configured SSH to only allow key-based authentication and change the port SSH listens on.  Both of these will make SSH more secure (remember that I am allowing external access to the server, so these measures are worthwhile).  Edit the SSH server's config file (/etc/ssh/sshd_config) and add or modify the following lines and restart SSH (more details):

PasswordAuthentication no
Port 1234

3. Allowed the client to login to the server by taking the id_rsa.pub file from the client and appending its contents to the file /home/user/.ssh/authorized_keys, (where user is the user name on the server).

4. My server is behind a firewall, (a cable modem/router thing), so I needed to forward the relevant port (1234, as configured above) from the router to the server.

5. I use dyndns.org to set up a constant DNS name for my router, which can use this service automatically.  Then I don't have to worry about remembering what IP address my ISP has given me or whether it has changed.

Then I prepared the client.

1. I checked that SSH was working on the local network before anything else.  In a terminal, enter

ssh -p 1234 user@192.168.0.10

Where 1234 is the configured SSH port and 192.168.0.10 is the server's IP address. The first time I did this I got a message telling me that the server's identity could not be verified.  I accepted this and entered the key's pass phrase.

2. The SSH client now needed to be configured to forward a couple of ports to the remote server.  This can all be set up on the command line, but it's easier to put it in a config file.  I edited the file ~/.ssh/config and added the following lines:

Host home
    HostName myserver.dyndns.org
    Port 1234
    User user
    Compression yes
    LocalForward 3483 192.168.0.10:3483
    LocalForward 9000 192.168.0.10:9000
    LocalForward 9090 192.168.0.10:9090

(where 192.168.0.10 is the IP address of the SqueezeboxServer on the local network).  Now using SSH from a remote location is as simple as typing ssh home and all the relevant addresses and ports will be used.

3. The client software I use is SqueezeSlave.  It's a headless (no UI) open-source software version of the Squeezebox.  Other players are available:
• SoftSqueeze is a Java clone of the Squeezebox itself, with a UI, display and all.  I found it unreliable on Ubuntu and over-sensitive to what else is running.
• SqueezePlay is ostensibly the replacement for SoftSqueeze but despite many attempts to compile it, it seems not to like PulseAudio on Ubuntu so although it functions as a controller, it won't produce any audio.
• Any software player that can work with MP3 streams, using these instructions.  The difference between using this method and using SqueezeSlave is that the server has to transcode everything to an MP3 stream first, whereas SqueezeSlave receives the raw bytes and plays them directly, locally.

Once downloaded, I put the appropriate version of the squeezeslave executable in /usr/bin

4. Now to run SqueezeSlave remotely, I first run SSH like this:

ssh -f home sleep 10

This runs ssh in the background and runs the sleep command.  This is a bit of a trick.  ssh will exit once it's run the command, *unless* the tunnel is being used.  So if you issue the next command within those 10 seconds, ssh won't exit until squeezeslave exits.

5. Then I run SqueezeSlave like this:

squeezeslave -m 00:00:00:00:00:03 localhost

where the -m option specifies a fake MAC address, which is used by the SqueezeboxServer to distinguish between players, thereby remembering settings for each player. The "server" is localhost because SSH is tunneling the requests for ports 9000 and 3843 to the real server.

6. I then control the player using the web UI from a browser at http://localhost:9000