The US server is being phased out…

This weekend (Feb 6-7th) all websites are being moved to the UK server, the US server will be phased out…

The only big loss is the end of the Urchin Stats as theplanet was offering $0 license for this application, however I don’t think it will be felt too badly…

The job is :

  1. change all DNS records to point all the domain from the old NS (ev1servers) to the new NSes (mydomain)
  2. Backup all the websites using pleskbackup and a list of, see this PDF for information
  3. Backup the Urchin stats (you never know)
  4. copy the backup over to the UK server
  5. Restore the backup
  6. Modify the DNS records for all domains.
  7. Cancel the US server (this will be done on Tue after all is moved and working OK)

deltacopy service won’t start

Question: The DeltaCopy service won’t start due to login failure. What can I do?
Answer: Symptoms You get the following message when trying to start the service.

Could not start the service. The service could not be logged on. Check user id and password specified for login.

DeltaCopy Server Service is a regular service on Windows OS, which requires a Windows user id/password to run on the machine. Follow the steps below to configure this.

* Go to Control Panel/Administrative Tools/Services
* Locate the service for DeltaCopy
* Click the right-mouse button and select Properties
* Click on the “Log On” tab
* Specify an Account and its password. DO NOT use the “System Account”. We recommend you use “Administrator”

Server Backups

The UK servers is synchronised with the US server, only but a few websites are active on the the UK server, in addition, an off-site backup is also planned to be used to save UK server content. This will take place in a few days.

If test are conclusive and the backup can hold all important data, we may do away with the US server. But there are no plans for this at present.

Passwordless SSH

Using encrypted keys for authentication offers two main benefits. Firstly, it is convenient as you no longer need to enter a password (unless you encrypt your keys with password protection) if you use public/private keys. Secondly, once public/private key pair authentication has been set up on the server, you can disable password authentication completely meaning that without an authorized key you can’t gain access – so no more password cracking attempts.

It’s a relatively simple process to create a public/private key pair and install them for use on your ssh server.

First, create a public/private key pair on the client that you will use to connect to the server (you will need to do this from each client machine from which you connect):

ssh-keygen -t rsa

This will create two files in your (hidden) ~/.ssh directory called id_rsa and id_rsa.pub. id_rsa is your private key and id_rsa.pub is your public key.

If you don’t want to still be asked for a password each time you connect, just press enter when asked for a password when creating the key pair. It is up to you to decide whether or not you should password encrypt your key when you create it. If you don’t password encrypt your key, then anyone gaining access to your local machine will automatically have ssh access to the remote server. Also, root on the local machine has access to your keys although one assumes that if you can’t trust root (or root is compromised) then you’re in real trouble. Encrypting the key adds additional security at the expense of eliminating the need for entering a password for the ssh server only to be replaced with entering a password for the use of the key.

Now set permissions on your private key:

chmod 700 ~/.ssh ; chmod 600 ~/.ssh/id_rsa

Copy the public key (id_rsa.pub) to the server and install it to the authorized_keys list (or open the authorized_keys list file and paste the content of id_rsa.pub into it) :

cat id_rsa.pub >> ~/.ssh/authorized_keys

Note: once you’ve imported the public key, you can delete it from the server.

and finally set file permissions on the server:

chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys

The above permissions are required if StrictModes is set to yes in /etc/ssh/sshd_config (the default).