Reggie Thomson’s Diary

Copy of email sent to Godaddy, 2006-08-20 16:48 BST

Dear Sir/Madam,

The domain lawandethics.org.uk was purchased on the basis that it would forward all traffic and email to a specified address (lawandethics.org). The domain does not expire until 9/20/2006, yet it has now been redirected to a Godaddy advertising page.

If the redirection is not restored within 24 hours, legal action may proceed against Godaddy.

Any further domains that are automatically expired by Godaddy prior to their expiry date may also be subject to legal action.

[Update 2006-08-20] Godaddy replied:

Thank you for contacting Customer Support. The registries of these TLDs require that a registrant renew their domain name before the 20th day of the month prior to the expiration month. This policy is referenced in the domain registration agreement.

For Example:
If a .jp, .co.uk or .de domain expires 1/31/2006… it must be renewed before 12/20/2005.
If a .jp, .co.uk or .de domain expires 3/19/2005… it must be renewed before 2/20/2005.

You still have the option to have us renew it for you and bring it back to an active state, but at this time it is pending expiration. You may verify this in your account.

If you would like us to renew lawandethics.org.uk for you please reply with the last 4 digits of the payment method you would like to renew this domain on (it must be a valid payment method that is already on file in your Go Daddy customer account) and the length of time for which you would like us to renew it.

Please note that if this domain has privacy this will have to be renewed at the same time and for the same length of time as the domain name.

Please be aware that this process usually takes 24 hours. Please let us know if we can help you in any other way.

It would be more useful if Godaddy sent emails giving the Actual expiry date, rather than misleading information.

Plesk 8.01 is still giving problems with backup to remote FTP.

I use a Godaddy FTP server as backup. However, Plesk seems to delete the old backup file without creating a new one.

My workaround is to do backups manually.

Using Putty SSH, I create a backup directory, eg. 20060816.

Then, in Plesk -> Domains -> (domain name) -> Backup Manager -> FTP Account properties, I change the FTP directory to “/20060816″, do a manual backup to FTP, then change the FTP directory back to “/”

Maybe someday Plesk will be reliable enough to work automatically.

Also, the FTP repository is not visible as an automatic restore, which is a nuisance. I’m assuming it will be possible to use FTP to bring the backups into the correct location on my server to make them visible.

[Update 2006-12-16:] Plesk 8.1.0 now has an improved backup, allowing FTP access and showing all FTP backups. The backup also includes statistics.

I started from scratch again with Joomla.

This involved:

1. Remove all tables from MySQL
2. Remove all directories and files from mydomainname.com
3. (Un)Tar the Joomla .tar.gz file
4. Make configuration.php writeable
5. Upload .htaccess as before
6. Make all necessary directories and subdirectories writeable using FileZilla
7. Run through the configuration from www.mydomainname.com
8. Note: the password for Admin was changed, and the email address set to info@mydomainname.com
9. When complete, remove the installation directory and all subfiles, subdirectories as requested
10. Made configuration.php unwriteable
11. Attempted to login with “admin” and “mypassword”

Fails to login!

Go to the website www.mydomainname.com - it’s got the default information on it.
Login as admin - This works!

Click on the “Administrator” button - asks for login again. Fails to login!

Solved problem: Incorrect settings on the sessions directory.

Plesk has changed the /var/lib/psa/dumps/ directory structure.

Now each user has a numbered directory, whereas before, the backups were stored in a directory for each domain name e.g. mydomainname.com
So, I removed the old directories by hand

rm -rf mydomainname.com

Installation notes:

Using Plesk 8.0.0 (updated from 7.5.4)

1. Used Plesk SSH to upload the Joomla.1.0.8.tar.gz file.

2. Plesk SSH: “tar -zxvf Joomla.1.0.8.tar.gz”

3. Access domain - gives Joomla installation check page.
Problems:

1. configuration.php Unwriteable
Uploaded a blank file and put file permissions to 666

2. Session save path /var/lib/php/session, Unwriteable

a) Tried Putty SSH to server; “su -”; “cd /var/lib/php/”; “ls -al”; “chmod 666 session”;

Fails. Probably because owner is “apache apache”

b) Tried creating “/var/www/vhosts/mydomainname.com/conf/vhost.conf” with contents:

php_value session.save_path “/var/www/vhosts/mydomainname.com/httpdocs/php_sessions”

Fails.

c) Created “.htaccess” file in “httpdocs” with contents:

php_value session.save_path “/var/www/vhosts/mydomainname.com/httpdocs/php_sessions”

Set file permissions of “php_sessions” to 766

See Joomla forums.

Works.

2. Display Errors - Off and Magic Quotes GPC - Off

Added two more lines to .htaccess:

php_value magic_quotes_gpc “1″
php_value display_errors “1″

Works.

3. Safemode off

This was sorted out in Plesk -> mydomainname.com -> setup -> services

4. Directory and file permissions unwriteable

Used Filezilla to change all.

This worked for the top directories, but the sub-directories remained unwriteable if I tried to change the file attributes simultaneously. I haven’t found a solution to this yet.

Technically, you lose Godaddy support. They only support the version they install for you. If the server has to be reinstated, it will be back to 7.5.4.
Also, the remote ftp backup breaks. You cannot automatically save backups to a remote ftp. However, in Plesk 7.5.4, the website was unavailable during backups. For small websites with low traffic, this is not a problem. For reggie.net, however, it used to take up to 15 minutes to do the backup - which was unacceptable.

I now do automatic backups locally (which don’t appear to take the website offline). Then I manually transfer backups to my remote ftp. Downloading to a home computer is also possible, but the file size seems to balloon (60Mbytes becomes 130Mbytes - maybe it is in zip format not bz2 or gzip).

There is also an Acronis TrueImage server, but it seems to just give an error. This would be useful. I assume Swsoft are working on an update to this.

I was not aware of these issues before pressing the “Update” button, but none of them are major problems. For security reasons, I prefer to keep up-to-date.

The dedicated server with Fedora 2 core uses MySQL version 3.23.58 (with Plesk 7.5 reloaded, which can be upgraded at no cost to 8.0, using the Update option in the Plesk control panel).

MediaWiki requires MySQL 4.0.14 minimum.

If you wish to use the Godaddy dedicated server for a MediaWiki, you will need the RedHat Enterprise 4 option ($24.99 per month extra).

Alternatively, you could risk upgrading MySQL outside the Plesk interface - see this article. P.S. I’ve just found this article on devnetwork.net on upgrading PHP/MySQL. I’ll write a post to see if anyone has tried the Godaddy upgrade route.
Personally, I will wait until Plesk issue an upgrade that includes MySQL 4. P.S. See above.

I had a brainwave this morning - to check Google cache for the contents of my photography blog. I couldn’t find it on Google, but it was all there in Yahoo’s cache. All I had to do was to copy and paste the individual entries, then change the timestamps and add all the categories.

Fortunately, I don’t get any comments on my blogs. The Chinese blog had two comments which I reinstated manually.

I’ve figured out how to backup using ftp to my Godaddy remote ftp space. Hopefully, next time I need the info, I can restore online, rather than from my backup at home.

I host a number of websites on a Godaddy server.

Today, I had to restore one of them from the online ftp backup, since the index.php was inadvertantly deleted by the owner.
However, when completed, the site continued to give a message saying the site was unavailable.

All of the files were correctly listed in the directories, and I even created a .htaccess file with the line “DirectoryIndex index.php”

This didn’t work.

I even tried disabling the website and re-enabling it, to no avail.

I had to restart Apache for the website to become visible again.