The solution: OpenDNS. These guys run a top-notch DNS service. It’s free, reliable, fast, and supposedly safer. The Getting Started page has detailed instructions for using OpenDNS’s servers in place of your ISP’s servers.

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:

1. the ssh -t option is necessary to force the correct terminal type. The excerpt from the GNU screen manual page:
   

   -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.

2. the “screen -R” command is appended to the ssh command and will execute on the remote machine after connection. The -R option will connect to any existing screen session if possible or open a new one if not.

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

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 went out to Wally World (Wal-Mart) and picked up the latest model without doing too much research. Mistake. Version 5 is piece of junk! It keeps dropping my SSH connections every few minutes and sometimes completely freezes up and I have to unplug and re-plug to fix it. Apparently, version 5 of the WRT54G contains vxWorks firmware instead of the Linux firmware found on older models.

The solution is to buy the Linux enthusiast’s version of the router, the WRT54GL, at a premium cost: ~$10 more. I can’t work with version 5, so I’ve ordered a WRT54GL and it should be here today or tomorrow.

Linksys: Did you really save that much more money by switching to vxWorks (+ less RAM)? What has this move cost you in terms of reputation and support costs on such a piece of junk?

UPDATE 04/05/06:I got the WRT54GL, and as expected, it ROCKS! I swiftly voided my warranty by putting DD-WRT on it. If you decide to do this, read the DD-WRT documentation carefully.

In Linux, you can undelete files if you are using the ext2 file system. A very handy tool called debugfs allows you to list files marked as deleted. I’m using the ext3 file system (ext2′s successor), so I thought the debugfs solution would work. Unfortunately, ext3 actually zeros out the block pointer (the pointer to the file’s data), so reconstructing the file becomes impossible with debugfs.

So, what to do? I had seen some mailing list posts refering to ‘grepping’ the data from the disk drive. Most everything I lost was code (specifically, Ruby). I attempted to use grep to search my hard disk device (/dev/sda7 in my case), but grep kept erroring out with “memory exhausted” errors. Hrrm.

A rethink of the problem led me to the ‘strings’ program, which extracts text from files, stdin, or even a disk device. I dumped all text from the disk partition to a text file like so:


#strings /dev/sda7 > /path/to/big_text_file


Note: It is probably a good idea to put the big text file on a separate partition. Otherwise, you risk writing over some of your deleted files on the partition you are attempting to recover from.

I was now able to open the big_text_file in vim and recover all of my deleted code by searching for particular code snippets. It’s not ideal, but I was able to recover everything. Instead of losing several days worth of work, I only lost a couple of hours.

And, of course, my backup is re-setup.

I had covered all of the bases:

• I could connect with sqlplus to my instance, so the Oracle client worked
• I had set the ORACLE_HOME with SetEnv in Apache’s configuration file and in bash’s system profile
• phpinfo() showed the oci8 module as installed and the ORACLE_HOME environment variable as set

This problem had me stumped a good part of an afternoon until I attempted to start Apache directly with apachectl instead of through the ‘service’ command used in CentOS. Suddenly, it worked!

A quick shuffle through the service script and I found that it was restricting the environment before calling the service like so:

env -i LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}"

Hmm. So, only LANG, PATH, and TERM are passed into any service environment: ORACLE_HOME is left out in the cold. And, even though I set it in the httpd.conf file, this is apparently too late for it to make a difference in the php oci8 module. A quick fix in the service script adds the requisite ORACLE_HOME:

env -i ORACLE_HOME=$ORACLE_HOME LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}"

The line above occurs a few times, so add to each occurance. Voila! It works.

I’m content with this solution for now, but I don’t particularly like having to change the service script, so is there any other way to do this?

Update:This is apparently a common issue: Debian mailing list comment, Gentoo bug, which is fixed with a white list of environment variables in a separate file. I couldn’t find a similar RedHat/CentOS bug. And, the SetEnv in the httpd.conf file is only effective for CGI PHP, which does not work for me because I’m using mod_php

So, I did some digging and found that the update log lives here (in default XP Pro): C:\Windows\SoftwareDistribution\ReportingEvents.log

Scrolling down through this text file I find the 9th column over to show the error number: 80264005

Google then brings up Ali’s helpful blog entry: Windows update gives a 80246005 error

Basic rundown: Stop the Automatic Updates service, delete the contents of C:\Windows\SoftwareDistribution\DataStore, restart the Automatic Update service and try the download/install of updates again.

Worked for me. Thanks, Ali.