I'm making an effort to separate my software development-related posts into a new blog: Curt's Software Blog. In addition to new posts, I'll be dusting off some of my older posts here and porting them over.
I've griped before about the lack of Flash Player version 8 or 9 on Linux platforms. Adobe is working on the issue, and significant progress has been made. More encouraging is the Adobe developer blogging about the progress of the project: Penguin SWF.
A beta version of Flash Player 9 for Linux was released on October 18th, and I'm happy to say it works quite well for me. There are still issues for folks on 64bit platforms, but hopefully those will be worked out in time. (It looks like it may be up to the distros to package the necessary 32bit libraries as dependencies).
Even more encouraging is the developer's preference for Gentoo!
In my last post, I wrote about setting up ssh-agent to streamline your connectivity to SSH remote hosts. In this post, I'll introduce screen, which I use in conjunction with ssh & ssh-agent to further improve my connectivity productivity.
screen is a console window manager that multiplexes between multiple terminals. If multiplexing was it's only feature, then it would not be anymore useful than any existing multiple-tab terminals available in a GUI environment. What really sets screen apart is its ability to open a screen session, detach that session from your connection, and then reattach it later on. In other words, if I'm using screen, I can completely lose my SSH connection, reconnect, and then reattach to the screen session–putting me right back to where I was previously working before the connection dropped.
You can read more in-depth at Jonathon McPherson's article on screen, but here's a quick run down of GNU Screen commands to get started:
$screen #start screen
$screen -r #reattach to an existing screen process
$screen -R #reattach if possible, or start new session
#within screen:
Ctrl+a, c #create a new window
Ctrl+a, n #switch to next window
Ctrl+a, p #switch to previous window
Ctrl+a, N #switch to Nth window (0-9)
Ctrl+a, " #list windows, choose with arrow keys and Enter
In my previous post, I setup a launch script for each remote SSH connection so that I could ensure that my ID had been added to the ssh-agent. I'm now going to tweak this script to launch screen upon connection to save me the trouble of typing "screen -R" everytime I reconnect:
#!/bin/bash
# ~/bin/sv1
ssh-id-check
ssh -t user@remotemachine.com "screen -R"
I've added two items to the script:
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
Now when I lose my SSH connection, I need only type the two or three-letters for my launch script and I'm put right back to where I was before the connection dropped. Nifty!
One additional tip:
If you use xterm and your scrollbar is not working, then put this into your ~/.screenrc file on each of remote machines you're using screen with:
termcapinfo xterm ti@:te@
see this info from the Screen FAQ
I spend pretty much all day connected to remote machines via ssh. It's key to my work and losing that connection for any reason is a big productivity vacuum. Lately I've been having some connection problems, which has prompted me to streamline how I connect to my remote machines. ssh-agent and screen are great tools for improving my connectivity productivity. I'll talk about ssh-agent in this post, and screen in the next one.
ssh-agent enables almost-password-free* logins to your remote machines. This is accomplished via SSH keys. You basically generate an encryption key pair on your local machine and then copy your public key out to each user on each remote machine. ssh-agent runs in the background on your local machine. You add your identity to the ssh-agent and supply a passphrase. As long as you keep your session (X session/login session) open and ssh-agent running, you won't need to enter a password when ssh'ing to a remote machine. This can significantly reduce your password typing during a day. Here's how I set it up:
$ssh-keygen -t rsa
Enter a passphrase when asked and remember it. Two key files are generated: your private key and your public key.
#key files generated on your local machine:
/home/username/.ssh/id_rsa
/home/username/.ssh/id_rsa.pub
You will need to copy the contents of your public key file (id_rsa.pub) to each remote user's authorized_keys file. If this file doesn't exist, create it.
#on each remote machine, copy your public key into this file:
/home/username/.ssh/authorized_keys
Now make sure that ssh-agent is running on your local machine. You want to run ssh-agent for your login or X session. I'm using Gnome and GDM on Gentoo, and ssh-agent is already setup for each session. If you need to add it manually, see this page: http://www.phy.bnl.gov/computing/gateway/ssh-agent.html
Now add your ID to the running ssh-agent:
$ssh-add
Enter passphrase for /home/username/.ssh/id_rsa:
Identity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa)
You can now SSH into your remote machines without having to enter a password. Try it!
*So, the only password you must enter is the passphrase for the identity you've created for ssh-agent. You will need to re-add this identity everytime ssh-agent is restarted (e.g., when you close your session).
In order to further streamline the password-entering, this script checks whether or not the ID has already been added and runs ssh-add if not:
#!/bin/sh
# ~/bin/ssh-id-check
# If no ID has been added to ssh-agent, then run ssh-add.
if [ -n "`ssh-add -l | grep has\ no\ identities`" ]; then
ssh-add
fi
Then, each of my SSH connections gets its own launch script that looks like this:
#!/bin/bash
# ~/bin/sv1
ssh-id-check
ssh user@remotemachine.com
I got the ID-checking script from here:
http://forums.gentoo.org/viewtopic-t-407440.html
Also read my post about how I use GNU screen.
I'm using Vim more and more these days for coding. Below are some useful Vim links:
It's nice to see Oracle tipping it's hat to PHP over the last year or so. PHP is very good at meeting specific web needs in the enterprise, and Oracle acknowledges this by including it in their Oracle HTTP Server (Apache, really) package. See the PHP Developer Center for more Oracle/PHP goodness.
Recent Comments