Waxing Cerebral

I use the awesome qemu open-source processor emulator, that lets you run virtual OSs (guests) on a host computer (on my Xubuntu box, in my case). Qemu has the power to have guest os's think they're on a box with entirely different processor types (eg have a PowerPC guest on a x86 box). But what I've found awesome is that with the relatively new Kernel Based Virtual Machine (aka KVM) on linux, with a supported processor, virtualisation goes right down to the cpu level - so it's fast!

If you're on linux and want to check if your processor does support it, use:

WebSphere lets you set the context root of a war file directly on page 1 of the update screens. ear files are different however:
Turns out when Updating an ear, you need to select on the first screen to show all build/config options.
Then skip to step 8 'Map context roots for Web modules'. There the context can be specified.

Having Xubuntu on my machine, gnome's Network Manager is an option, but I try to avoid the bloat of gnome. A great alternative (which many say is better) is wicd. It successfully scans for wireless networks, handles WEP connections, and is the only way I could find to connect to WPA/WPA2 networks. Great product. (howto)

I have been frustrated on numerous Linux systems where I have to use custom boot switches in Grub, so add them to the relevant entry in /boot/grub/menu.lst, but then a new kernel version (which adds a new boot entry) then doesn't have this new option. This has been simply annoying in the past because I've had to go back in and add the text to the entry. But now I've built a machine for a paying customer and I can't go round every time there's a kernel update!

It turns out the solution is simple:
Between the flags
### BEGIN AUTOMAGIC KERNELS LIST
and
## ## End Default Options ##
are settings that the updater will read in order to create the new boot entries.

The one we want is

Add text here and it will get added to any new boot list entries.


While I'm on the topic, another useful setting in this set is
which lets us reduce the number of kernels that remain as options in the boot list

//Lock this hibernate session so we don't get lazy loading exceptions
SessionFactory sessionFactory = (SessionFactory) appContext.getBean("sessionFactory");
Session session = SessionFactoryUtils.getSession(sessionFactory, true);
TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(session));

Using ssh we can create tunnels to route bi-directional traffic. Depending on our selection of destination and server computers to connect to, the complete tunnel is made of a fully secure ssh tunnel, and possibly an additional tunnel continuing on that is not secure. The examples below should help explain this.
Here's the command:

ssh -NL localport:targethost:hostport server [-p serverport]

Where

• -N means don't start a remote ssh session (useful if just port fowarding)
• -L indicates a tunnel is to be set up with the following params:
• localport: tunnel 'entry'. Port number to connect to locally (ie at localhost)
• targethost: tunnel 'destination'. Which computer (name or ip) to connect to
• hostport: tunnel 'exit'. Port number to appear as on the other side of the tunnel.
• server: computer to validate ssh connection on (needs to be running ssh server). This forms part of the tunnel and three variations of this are explained below. You can make this 'user@server' in order to specify a username for the authentication if required.
  
• serverport: this is optional, but if you want to create the ssh connection over a non-standard port (ie not 22) then use this. You'll need to get the sshd listening on the new port in this case.
  

Remember these funky things are 2-way so if whatever you're communicating with at the other end of the tunnel sends info back down the tunnel (via hostport) then you'll get it right back at your end (localport). It's cool.

Example 1, target computer is running ssh server:
ssh -NL 8081:192.168.1.4:8090 192.168.1.4
Create a tunnel from 8081 locally to 192.168.1.4, and appear there at port 8090. Validate at 192.168.1.4. This is a short tunnel, between just the client and host, but completely secure. All traffic in this case will be over port 22 (ssh default).

Example 2, host computer is running ssh server:
ssh -NL 8081:192.168.1.4:8090 localhost
Exactly as in example 1, only this time the local machine is both ssh server and client. There is effectively no secure tunnel here (ie it's only between ports on the local machine), so unsecure over port 8090 to 192.168.1.4.

Example 3, 3rd computer is running ssh server:
ssh -NL 8081:192.168.1.4:8090 192.168.1.5 -p 3389
In this case, locally we are the ssh client, connecting securely (over port 3389) to the ssh server, 192.168.1.5. From there traffic travels over port 8090 to the destination box, 192.168.1.4. This is very powerful as traffic can be securely routed into a limited-access network. For example in this case if Microsoft's Remote Desktop Protocol (RDP) was the only traffic allowed in and out (eg through VPN), then the client externally can run this command, connect through on the RDP port (3389), connecting to a box inside the network (192.168.1.5). From there the destination IP is resolved, so this needn't be visible from the client computer, and traffic flows freely inside the network over 8090.

Another option is remote tunnels (instead of local tunnels). These use essentially the same commands, but with -R in place of -L. With a remote tunnel it is possible to declare a port on a foreign machine as the tunnel entry.

A nice way to test your tunnel is to use netcat. For the above examples this test would be:

On 192.168.1.4:
nc -l -p 8090
listen (-l) on port (-p) 8090 - end of the tunnel

On localhost:
nc localhost 8081
connect to localhost on 8081 - start of the tunnel

The localhost connection should get tunneled to the remote box and you'll be able to type at either end and see it appear in the terminals.

Bash scripts are fantastic. I could end the post there, but they can be made even better for end users by using one of the simple GUI applications out there that can be run from bash. Here's a great little example (using gtkdialog)that pretties-up the interface for my infrared phone script from this post.

Beautiful

If you're in NZ, and you've got TelstraClear cable internet, congrats cos that's the best option we have.

But if you have the experience I've had, you'll be tearing your hair out. I have a couple of computers at home (only my wife's work laptop runs Windows :) and a Netgear router (WGR614 v7) connecting them to the cable modem. Since the first weeks of having the setup though, the internet connection drops off way too often (3-4 times in a work day). Telstraclear and the modem were fine; connecting just one computer direct to the modem would chug along for weeks without issues. I am on my second replacement router (that means 3rd in total) and have had conversations with Dick Smiths (router retailer) and Netgear, and still have the same problem.

Frustrations!

So today I managed to talk directly to the right people at TC to help me troubleshoot things. And lo! I have the wrong type of cable modem!!
That's right, they have two (at least) models they provide customers with, the Motorola SB5101 and 5100. I had been given the 5101, and not knowing there was an option, had blindly accepted it as the modem.

TelstraClear cable customers using a router should be provided a model 5100 cable modem.

If this is you, and you are having these problems then call them. They should replace it without a call-out fee if you had a router from the start. And how are we mere customers supposed to know this? Beat your head against various unyielding walls for a year seems to be the answer...

EDIT: Just had the modem replaced this morning. Turns out the 5101's were introduced to be more compatible with Windows XP! What a joke - you know not everyone uses Windows! And the 5100's won't fix the problem, but they should reduce the disconnects. The main cause is an issue with TC's hardware, for which they're getting in some new equipment which should resolve the issue by the end of February 2008.


Also, on the topic of things TC doesn't tell you about their cable internet service, they recently rolled out a 'customer security' measure whereby any change in MAC address connected directly to the modem will not work for a stand-down period of a number of hours. So if you change computers that are directly connected (or switch from router to computer while troubleshooting!) then you won't get a connection anyway. That took a bit of figuring out at the time. You have to ring them and ask for that 'feature' to be removed from your account. It does have security benefits, but it's a wired connection, so someone would have to be sneakily plugging into your modem or cable anyway.

Good service, but keep us informed Telstra.

Apt needs to be configured to use a proxy if you're using one (eg if using cntlm). This is done by creating /etc/apt/apt.conf.d/proxy, with content similar to:

Acquire {
Retries "0";
HTTP {
Proxy "http://127.0.0.1:3128";
};
};