Consilience Blog

Plesk-based hosting can often suffer from a resilience problem: failure of the DNS for sites it hosts if the server goes down for any reason.

Ideally a zone should have a number of domain name servers located in different places. A zone is basically a domain and all its sub-domains. The zone record tells other servers where to find everything for that domain – where the websites are, the main servers etc.

Plesk run on a server or virtual server (VPS) generally provides two name servers. They will be configured automatically when websites are set up on the server, and are very convenient to use. Plesk also allows some customisation of the domain records so that, for example, a sub-domain can point to another server, or the mail server points to your office server.

The problem comes when the server running Plesk is down or inaccessible. A mail server trying to send an email to your domain will suddenly find there is no record anywhere of that domain – it has basically dissappeared.

The way around this is to use external name servers. By setting up the external name servers as a slave servers, they can be made to automatically keep themselves updated from your master name servers on your hosting machine.

For our domain, I used www.zoneedit.com to set up a slave for one of our zones. The slave was pointed at our hosting server (using its IP address) and that was it for that end – the zoneedit slave just fetches updates when it is appropriate and updates its own records, putting them onto two geographically-separated name servers of its own.

Back to the domain registration settings, I then needed to add the zoneedit name servers to the domain, giving me four in total (the two on our Plesk hosting and the two on zoneedit). There is no priority assigned to any of these name servers, so a server looking for our website or mail server could go to any of these sources. It is therefore very important to ensure they are all synchronised identically.

One last step was to tell Plesk to allow these name servers to fetch a copy of the zone records. This is not so obvious but is in Plesk under the option:

Server -> DNS Settings -> Common ACL

In here I added the IP addresses of the two zoneedit name servers assigned to my zone, and then the updates simply went ahead.

You can test this works using nslookup command from another server. Create a new sub-domain, then check it can be seen on your Plesk server:

nslookup new.sub-domain.example.com ns.plask-server.example.net

Then try the same command but pointed at the external name server. You will find the external name server cannot see the sub-domain immediately. Try again in an hour – and it should be there. If not, check your setting and TTL etc.

Hopefully that will give you more resilience; even if your website is down, other severs that your zone points to are still locatable.

One thing that I am still looking for a solution to, is domain aliases. A domain alias for a domain set up in Plesk will not get transferred to the slave name server. Even if the alias is a sub-domain of the main domain, it does not get transferred. So the hosting server will correctly return the IP address for example.com for the alias myalias.example.com, but the slave name servers will not. This is not just a problem for when your hosting server goes down, because there is no priority on the name servers – all and any could be used at any time for a server to locate your alias domain, and depending on which name server it hits, it is pot luck as to whether it finds it or not. I’m looking for a solution to this, so any hints appreciated.

I’m also looking for a decent and cheap slave name server service. zoneedit is good and reliable, and easy to use, but could get costly when we have scores of domains to sync up. Any suggestions?

Follow me on Twitter

This is something that has been bothering me on the odd occasion for years. It is intermittent, so is something I have been able to live with, but it would be nice to get to the bottom of it.

Basically, there is a key combination – somewhere around the “A” on my keyboard, probably involving the control and perhaps the shift keys, and is so easy to accidentally press when not being careful, that locks up all my keyboard input.

When I say “locks up”, I mean that the keyboard becomes completely unresponsive. Nothing gets it back, except a full reboot, and if you know how long my PC takes to boot, you would realise it is not very convenient (I do manage to make a cup of tea while it boots, which is a bonus, kind of).

I have tried unplugging and plugging back in the keyboard. I have tried undocking the PC (I use a Toshiba Tecra laptop in a docking bay). I have tried logging off and on again. Yes, I have tried logging off and on again. None of this works; only a full reboot does the job.

It locks up both the external Logitech keyboard and the laptop’s built-in keyboard, so there appears to be no workaround.

So – what could this be? I have a feeling it is some kind of “feature” that is misbehaving, but cannot think what it could be. I have not even been able to find the key combination purposefully to give me any more clues. It just happens, and when it does I know my fingers were pressing some keys around the “A” end of the keyboard.

I have a feeling I will never find a solution to this. Perhaps I need a new laptop.

Follow me on Twitter

Trying to make sense of theme inheritance in Magento, I have started to put a simple script together to help navigate the themes installed on a shop. When I say simple, I mean very simple. Jump straight in and have a browse:

http://magento.consil.co.uk/themes.php

This script is installed in the root directory of our 1.4 test installation.

What it gives you is a layered approach. First you select the interface, then the theme within that interface (try default->modern for example).

The script will then list all the layout files that make up that theme, and show you where those layout files come from, i.e. which parent themes they are inherited from. A complex theme may consist mostly of its own layout files (the iPhone theme for example). A simpler theme may override just a few layout files, choosing to fall back to the default theme, or the new “base” theme in Magento 1.4.

For each layout file, the handles are listed. Each handle provides some unit of functionality in the theme – usually a block or a widget – some simple, some very complex. The next step will be to document what all these handles do, and how they get called up. Some are invoked from the Magento core, some from modules, and some from other templates in the theme, so it can all get very complex very quickly, leaving the average themer lost when they only wanted to change a few aspects of a theme.

It is the content of the handles that are the really important part of a theme. The layout files just provide a convenient way to package together a number of handles in one place. The same handle can appear in multiple layout files, and they are simply chained together in alphabetic order (of the name of the layout file).

What the layout files do is allow a module to keep all its handle-based theme functionality in one place. A theme developer could also use it to keep all their theme additions in one place too – there is no point spreading that functionality all over a custom theme by overriding dozens of layout files if all you want to do is tweak menus and blocks.

By clicking on the “handle” link in the script, the table gets inverted – now you get to see all the layout files that each handle is included in.

Selecting a handle will list the contents of each instance of those handles – the XML instructions to the theme engine.

To take this script further, it would make sense to interpret the content of the handles. Ultimately it should then be possible to do searches on those interpreted instructions to find, say, where a particular block or image is displayed from.

Feedback is welcomed – is this any use? Should I publish the script? Does anyone want to expand on it, perhaps packaging it into a module to help theme developers?

Download the script here: themes.zip (contains theme.php, to be copied to your Magento root directory).

Follow me on Twitter

Occasionally there is a need to send a fax, but it can be such a rare occurrence that it is hardly worth keeping a fax permanently set up, or even keeping track of where you last put the fax modem cable for your laptop.

I took a look at free or cheap online fax sending services in the UK, and many offer lots of promise in the Google search results, but few deliver once you go through their long registration processes – usually “free” means “subscribe monthly” by the time you get to the site.

I did come across FreePopFax though that seems to work a treat. Just upload your Word for PDF document, enter the recipient’s fax number and your e-mail address, and off it goes. You then get an e-mail when the fax is sent.

So far as I can see, FreePopFax is an affiliate of the monthly subscription service PopFax, but adverts are inserted to pay for the service. Bear that in mind – the recipient may receive adverts.

I would add a disclaimer: I have no idea who is reading these faxes en-route, so don’t use it for anything that contains credit card or other personal details that could result in identity theft, but for the odd fax, give it a go.

Follow me on Twitter

The Plesk web management interface is pretty cool. There are lots of sophisticated things you may want to do on a web server, but 99% of those tasks are encapsulated into the admin screens provided by Plesk; it simply gets the job done of managing web hosting.

Every now and then you will probably want to reorganise the domains, clients and databases within a server. One task includes moving a database from one domain to another.

At the server level there is no concept of a database being owned by a domain – all databases are global to the server. Within Plesk, however, each domain has its own associated databases which can only be managed from within the account that owns that domain.

To move a database to another domain, you can export it, delete the old database, create a new one in the new domain, then reimport the database. There is an easier way though.

Log into the server using ssh then issue this command to get into the MySQL command line tool:

$ mysql -u admin -p -D psa

You will need to enter your Plesk admin password.

Next take a look at the current database list:

mysql> select * from data_bases;

+----+-------------------+-------+--------+--------------+-----------------+
| id | name              | type  | dom_id | db_server_id | default_user_id |
+----+-------------------+-------+--------+--------------+-----------------+
|  1 | consilience_db    | mysql |      1 |            1 |               1 |
|  2 | client1_db        | mysql |     18 |            1 |               2 |
| 29 | client2_db        | mysql |      6 |            1 |               4 |
+----+-------------------+-------+--------+--------------+-----------------+
3 rows in set (0.00 sec)

Each database will be listed with their name and “dom_id” (domain ID). Find the ID of the database you want to move, and find the dom_id of the domain you want to move it to (the dom_id will appear in the URLs used to manage the domain in the Plesk admin screens). Then update the dom_id, for example to set database ID 29 to be owned by domain 18:

mysql> update data_bases set dom_id = 18 where id = 29;

That’s it – the database will now appear under the new domain in Plesk.

This will only work on a single server. If you are migrating between servers then there are other tools for the job.

Follow me on Twitter