BigSmoke

Smokes your problems, coughs fresh air.

Tag: PuTTY

Using Caps Lock as an extra Control key

July 15, 2008 /

With me mostly posting about computer stuff on this weblog, it might surprise you that, until May this year, I hadn’t owned a personal computer in years while the last one that I did own was a slow pig grown from some old parts of an even slower pig and some second-hand replacements. So, you can image my joy when I got a shiny, new Lenovo Thinkpad 61 this spring.

One of the joys of once more owning a personal computer is that I don’t have to live through PuTTY anymore. (I used to SSH to the local Debian server here if I wanted to get anything done.) I’ve reacquainted myself with Gentoo and I’m loving it. Of course, there’s a lot more to configure than with Ubuntu (which supports the T61 very neatly out of the box), but that’s the whole point; I want to be able to configure everything my way and I want to update my knowledge about how Linux systems are made up these days. Control.

On the topic of control, the Control key on the Lenovo keyboard, as with many laptop keyboards that I’ve encountered, is in a bit of an awkward position, squeezed to the right by the Function key. Since, I very much depend on the Control key for shortcuts (in just about anything, but especially in libreadline-based programs), I decided to change the Caps Lock key to be an extra Control key. I’ve never actually used the CapsLock key in my life, I probably never will, older keyboards used that very spot for the Control Key, and why not? It’s a much better spot, requiring less gymnastics for my little pinky to reach. Once I considered this I was actually puzzled about why I’ve always wasted such an well-accessible key position.

X

On to the configuration. I wanted this to work in both Console mode and in X. But first X. In the xorg.conf, I went to the InputDevice section for my keyboard and added ctrl:nocaps to XkbOptions. The full XkbOptions line now reads:

Option "XkbOptions" "ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e"

That’s it. I had to take a few more steps to get it to work in the console also.

Console

First, I created a file called “/etc/extra-key-conf” with the following contents:

keymaps 0-15
keycode 58 = Control

Then I added the following to /etc/conf.d/local.start. This is a Gentoo specific script that is loaded by /etc/init.d/local.

[ -z "$DISPLAY" -a -e /etc/extra-key-conf ];
        loadkeys /etc/extra-key-conf &>/dev/null

What this does is to check if the $DISPLAY variable isn’t set (of which we can be sure in this context, but may be useful if you plan to copy this snippet). It also checks if /etc/extra-key-conf exists. If both conditions are satisfied, loadkeys is called with that file as its argument.

In conclusion

I can really recommend this configuration even if your Control key is not awkwardly positioned on your keyboard. Do you use your Caps Lock key? Regularly? If you don’t, this will make your keyboard use more effective.

Reference

If you want to read into this more extensively, I recommend the Remap Caps Lock article from the Portland Pattern Repository.

Getting your terminal unstuck

January 13, 2008 /

Have you ever had your terminal freezing on you for a reason you can’t identify? Fret no more, because this post will save your future login session.

Your problems are most likely caused by sending an XOFF character to the server, by pressing CTRL-S. The XOFF character is a flow control character, which instructs the server to stop sending data. To undo this, you need to send an XON character, which you can do with CTRL-Q.

Misfortune would have it that CTRL-S is the forward search command of the readline library. This makes searching in your bash history, among other things, a little annoying. Luckily, you’ll mostly use CTRL-R, for backward search, but sometimes you need a forward search as well. I would welcome any suggestion as to how to use CTRL-S without having your terminal freezing on you. The terminal program I use, Putty, doesn’t seem to have an option for it.

Using an outgoing SSH tunnel from behind a NAT for incoming VNC

February 17, 2007 /

Laurelin is working as an Au Pair for a Greek family in—where else than Greece. Her hostess has arranged for an Internet connection through Vivodi Telecom to allow Laurelin to maintain some form of contact with her friends and family at home.

Once connected, Laurelin quickly installed the Azureus BitTorrent client to be able to download some things (only legal things licensed under a liberal license, of course). Correct usage of the BitTorrent protocol implies opening up a port or two for incoming connections. After all, BitTorrent is all about sharing.

So, she needed help configuring port forwarding on the ADSL modem / NAT router (a microcom AD 2636) in Greece. She asked for this help two days ago while Wiebe was looking at my screen, because we where doing an extreme programming session on a database schema using VNC and Skype. We interrupted our work hoping that we could easily solve her problem.

I had been looking at screenshots and manuals of her router and her modem’s administrative interface earlier when they couldn’t get the connection to work. After making sure that the problem was not a configuration or software problem and identifying that there was probably a problem between their modem and their telephone exchange, they later got their problem fixed. So, now I had to dig up the manual again. But, this time I could only find some screencaps which accompanied a useless tutorial in Greek. This exemplifies why I think it is useful to keep a blog.

So, Wiebe and I did our best to guide her through a GUI we couldn’t see and eventually she succeeded in defining a few forwards. However, they didn’t do their job. According to nmap they were still filtered. She then installed RealVNC server for us and added port 5900 to the list of forwarded ports. Wiebe tried to connect using the kvnc client, but no response. By that time, we had fooled around quite a bit and after mucking about a little more, we decided to postpone the rest and return to our database design. We decided for next time to let her use PuTTY to put a hole through the NAT router.

Today was the next time. She installed PuTTY. I gave her an account on the Debian server in our local LAN (I am behind a Windows terminal myself). Now she had to set up a tunnel and connect to that account:

Configuring a remote tunnel for VNC in PuTTY

At this point, I still couldn’t access the tunnel between her box and the Debian machine from my Windows terminal:

$ netstat -l -n|grep 5900
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:5900          0.0.0.0:*               LISTEN

Since PuTTY was configured to let remote ports accept connections from other hosts, the problem had to be in the OpenSSH configuration on the Debian box. And indeed it was. I had to set the following option:

GatewayPorts yes

After a restart of the OpenSSH daemon, she opened a tunnel which I could access from my own machine:

$ netstat -l -n|grep 5900
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN

I could now control her desktop through the RealVNC viewer. Next time, I’ll need to actually do something with this connection.

© 2024 BigSmoke

Theme by Anders Noren — Up ↑