I’d been a regular user of SSH for several months before I discovered screen. For the uninitiated, it allows you to create multiple ‘windows’, each containing as shell, inside a single SSH session. It also allows you to detatch the whole session from the terminal, log out, then log in and reattach it later, with all programs that were running in it still there. I’ve now fixed up my SSH logins to automatically reattach my screen, and create it if it isn’t there:
ssh -t david@machinename screen -d -R
In PuTTY, the ‘remote command’ option in the SSH config area (as per the relevant manual section) achieves the same effect.
This ‘automatically-reattach-or-create’ stuff all worked fine on one Ubuntu, three Debian, and one Solaris machine when I tested it last week, but trying to log in to the Solaris box last night produced
bash: screen: command not found
I think this is because the screen binary lives in /opt/sfw/bin/ on these machines for some reason, hence it’s not in the default PATH variable. It is in my user PATH, but I presume that isn’t loaded when SSH tries to execute the command. Anyway, specifying /opt/sfw/bin/screen rather than ‘screen’ in the SSH command solved the problem.
I needed to set up a Planet recently, and there appears to be very little online documentation about the process. To be fair, if you install it on Debian using apt-get, debconf will walk you through most of the setup, and it drops some examples into /usr/share/doc/planet to get you started, but here’s my quick guide anyway:
How to install planetplanet on Debian
Follow these instructions at your own risk:
- sudo apt-get install planet
- Follow the prompts from the installer to fix up your basic configuration
- Create a virtualhost on your web server if necessary, and make the directory which the planet URL will map to
- Edit /etc/planet.conf to change the output_dir line to the directory you just created
- debconf should have set up a cron job to update the planet if you asked it to, but meanwhile you might find ‘sudo planetplanet /etc/planet.conf’ handy to manually update it whilst checking it’s all working.
My friend and web host, Martin, recently decided to scrap his old server running DirectAdmin, and replace it with a shiny new CentOS VPS running Plesk. Having spent an enjoyable day with him last week rummaging in the bowels of the old server trying to fix SpamAssasin, I agreed heartily with his decision. I got dnorth.net over to the new machine with reasonably little fuss, apart from a few minutes when I hosed the DNS by being in too much of a hurry. I also forgot to copy the .htaccess file, which resulted in everything but the front page of this blog being down for several hours. Of course, I didn’t check anything except the front page.
Moral of the story: command-line scp doesn’t copy files whose names begin with a dot, unless you explicitly tell it to, i.e do this:
scp -r user@host:'/dir/* /dir/.*' destination-dir
Rather than this:
scp -r user@host:'/dir/*' destination-dir
And just because the front page works, that doesn’t mean the rest of the site is OK…
The problem: Windows doesn’t have an inbuilt SSH client, so trying to check out files from a Subversion repository over SSH doesn’t work out of the box. I’ve just spend half an hour looking for a way round this, and here it is [as ever, you follow my advice at your own risk]:
- I couldn’t manage to get it working using PuTTY. Please leave a comment if you have.
- Install Cygwin, making sure to include the openssh package
- Edit the C:Documents and Settings(yourusername)Application DataSubversionconfig file to include a line reading
ssh = c:/(cygwin root path)/bin/ssh.exe -i "C:/privatekeypath"
- You can omit the -i option and the bit after it if you don’t have SSH key authentication set up. If you’re using it, though, make sure you use forward slashes in the path to the key file. Note that the private key needs to be in OpenSSH compatible format. If you have key authentication set up in PuTTY, you can export your private key to an OpenSSH compatible version using PuTTYgen.
- You should now be able to check out repositories in the usual way from a command prompt:
svn co svn+ssh://you@repositoryhost/path/to/repository/ destination-dir
If you exported your PuTTY key as described above, you shouldn’t be prompted for your password on hosts where the corresponding public key is in place.
Since writing this post, I’ve had Tortoise SVN recommended to me, and it Just Works out of the box if you use the PuTTY saved session name in the URL, i.e. if the PuTTY session is called “mybox”, svn+ssh://mybox/path/to/repo seems to work correctly.