WRITING AND SOFTWARE BY IAN SHARPE

Host multiple web sites on one account

If your web hosting package doesn't explicitly support multiple sites, this account of my experience will help you explore the possibilities and decide what to do

Note: The original version of this post was written a long time ago. Roadblocks I encountered at the hosting company I was using then may not apply there now so the company's name is not mentioned. Some information here may be a dated but a lot should still be relevant. I recently added notes about the most recent stage of my multi-site hosting journey, with talk of my move to DigitalOcean and use of ISPconfig. This is a long post that I will paginate into chunks sometime. Until then, these are links to places further down in the article: DigitalOcean, ISPConfig

A decade ago, I worked on a small personal e-commerce venture, Luxartis.biz. The site needed server-side scripting and a database. PHP and MySQL were my preferred tools at the time. I didn't expect many visitors to start with.

The hosting plan for iansharpe.com had all the needed features and my personal site only used a fraction of the space and bandwidth allowances. What could be more natural than to host the new site alongside it and exploit some of the spare horsepower?

Easy! There are several ways to do it. One of them had to work… didn't it?

Not so fast

I went all around the houses before realising that no matter how good the headline figures are for shared web hosting, there may be serious but less obvious limits to what you can do.

Initially, I put Luxartis in a subdomain to keep it physically separate from iansharpe.com. This took a moments to set up in my site administrator control panel. Luxartis then resided at luxartis.iansharpe.com (it isn't there now).

The luxartis.biz domain was then registered with GoDaddy.

Forwarding the domain

To begin with, from GoDaddy, I set luxartis.biz to forward to the subdomain. Doing this meant that entering www.luxartis.biz automatically redirected the visitor from GoDaddy to the Luxartis home page, but the address bar showed luxartis.iansharpe.com.

I wanted the paid-for URL displayed, so I turned on masking.

Also known as cloaking, masking causes the domain registrar to create a page for you on its own site. This contains very little apart from a frame. When a visitor enters your domain address, they get the container page hosted by the registrar. The frame pulls in content from your web site. URL and content appear to be married but in reality two web servers are working in tandem.

It's a flawed marriage. For instance, no matter which page is viewed, only the bare domain name is displayed in the address bar. This may or may not affect the ability to bookmark a specific page. It depends on the browser.

I don't know the full effect on search engine, but I cannot believe it never has adverse consequences on SEO.

Furthermore, the metatags on the real page do not become the metatags for the framing page. The 'keywords' tag is reputedly almost obsolete for the purpose of search engine indexing. But even so, metatags in general are functional elements and need to work properly.

GoDaddy enabled me to create 'title' and 'keywords' metatags for the framing page. This turned out to be one setting for the whole site, not a custom setting per target page. That's another SEO no-no.

Some registrars offer other systems, such as automatic HTTP redirects. Nevertheless, I preferred to stay away from workarounds.

In addition to the disadvantages mentioned so far, there is the matter of speed. With forwarding, there are always two web servers involved: the registrar's and yours. This seems certain to increase the average time taken to load a page.

Luxartis was a commercial operation. Penny-pinching sub-optimal kludges acceptable on a hobby site may lose business when SEO, image and usability assume prime importance.

Unique IP for a subdomain

I really needed requests for Luxartis pages to be sent direct to my server, just like any normal site.

If I set the new domain to point to the IP address of iansharpe.com, Luxartis visitors got iansharpe.com content, but with www.luxartis.biz in their address bars. No good.

So the next option I looked at was to have a second IP address assigned to my site. Sometimes it is possible to assign a subdomain its own IP address. This could be a unique target for luxartis.biz.

Only, it wasn't an option on my hosting plan. One IP address is all that was allowed. If I rented a whole or virtual server (VPS) from the same company, I could buy pairs of additional IP addresses for it.

But for a tiny business I did not want or need the resources, expense or admin overhead of a dedicated server. Not only that, but the extra addresses cost almost as much as separate cheap hosting. This was starting to look like the least troublesome option but I hadn't finished exploring the technical fixes.

Virtual hosts

Moving on, I investigated what the Apache web server has to offer. Virtual hosts seemed to be the answer. Apache can be set up to run multiple sites on one IP address. Requests for content from different sites are distinguished by the target domain names supplied by the browser. This will fail with browsers that don't supply the required information. Don't worry about them. Modern ones behave as expected.

Once again, I had a potentially good solution… only, my hosting plan didn't give access to the Apache configuration file. This is unsurprising because it is the mechanism by which the hosting company provided my own site on its shared hosting server. Also, virtual hosts can make life more difficult if you want an SSL certificate (to give visitors secure https://… access)

What about .htaccess?

Next port of call was Apache's .htaccess file for my site. I was allowed to tinker with this. Provided Apache's rewrite engine module, mod_rewrite, is available, .htaccess allows you to intercept incoming requests and modify them in various ways before the server retrieves and transmits the content.

One of the techniques that .htaccess makes possible is to redirect a request to another file, possibly located in another directory or on another site.

Optimism sprang anew. This had to be it. I could put an .htaccess file in the root of iansharpe.com, trap requests for luxartis.biz, and redirect them to files in the Luxartis subdomain.

This is where the real head banging began. The .htaccess file is incredibly flexible. As is noted in many other places, the price of flexibility is complexity.

Mod_rewrite makes use of regular expression matching. I am comfortable with regex these days but found it harder back then. For this reason, I put my inability to get .htaccess working quite as I wanted down to my own mistakes.

In fact, I had run up against another hidden barrier, and quite a subtle one.

I fairly quickly had .htaccess working to the point where the redirections were being performed, giving me two web sites running on one hosting plan:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^.*luxartis\.biz$ [NC]
RewriteRule ^.*$ http://luxartis.iansharpe.com [R=301,NC]

This looked for luxartis.biz in the requested URL and, if found, rewrote it as a request for the subdomain. The problem was, the Luxartis subdomain was appearing in the address bar. The whole point of this unexpected adventure was to prevent that!

Internal vs external rewrites

The mod-rewrite documentation is dense and various tutorials I found either regurgitate it without much tenderising, or are very skimpy, or manage a pointless combination of both faults. Why do these people bother?

I kept bouncing back to the official manual. On the umpteenth skim-through, the penny dropped.

I had discovered elsewhere that redirections that report code 302 to the browser are undesirable. This code signifies that the requested page has moved temporarily, and search engines tend to ignore such pages. What's needed is a code 301 redirection, indicating that a resource has moved permanently. This is much more acceptable.

If you don't add parameters to your RewriteRule lines in .htaccess, you're probably defaulting to 302 rewrites. If this isn't what you want, you can append the [R=301] flag to change the return code.

Reviewing that portion of the mod_rewrite documentation, I noticed that it refers to external rewrites. Elsewhere, it mentions internal rewrites. Suddenly, I realised that external rewrites 301 and 302 tell the browser about the redirection, causing the re-written address to load into the address bar. An internal redirection should do the job invisibly.

[Note: The following statement may be incorrect - will check and update soon] Internal redirects are forced with the [P] flag and require Apache's mod_proxy module to be present.

Guess what? The [P] flag did nothing more than generate server errors. Had the hosting company's techies deliberately blocked this final escape route, or could it be enabled if I asked nicely?

Time to fire off a support request. I thought I knew the answer – some sugar-coated version of "we don't give you that so we can sell you something better" – but had to ask anyway.

Not on our servers...

The official word was that this feature was unsupported in my hosting plan. Well at least it proved that the system engineers had a clue about managing cheap web hosting.

That was the end of the quest for clean co-hosting with that company. My choices seemed to be as follows:

  • Live with the forwarding and masking, and review it when I had monitored the effect on search engine visibility.
  • Find a separate PHP/MySQL hosting plan for Luxartis.
  • Demote iansharpe.com to a subdomain and make Luxartis the primary site. However, iansharpe.com has a decent search engine rank due to all the big sites that point to my free software. This is useful for promoting other sites that I have an interest in. I don't want to spoil this, so it would need monitoring if I swapped the site priority.
  • Muck around with redirects in the page headers. More kludgery and I didn't like the sound of it.
  • Upgrade to a plan with the required functionality for multi-site hosting. At the time, none of the company's shared hosting packages appeared suitable. It was VPS or nothing with them.
  • Abandon my hosting plan and move to a company that allows multiple domains on one account.

Otherwise, I could be looking at a VPS or VDS (virtual private/dedicated server), which works like having a server all to yourself, but it is virtualised: it runs in parallel with several others on the same hardware.

VPS/VDS is a stepping stone between cheap shared hosting and an expensive fully dedicated server. The downsides were that it cost a lot more than I was paying for shared hosting and I'd be responsible for server administration at a level I didn't want to make time for.

And the answer was...

Version 1 of the site was ready to go live and I had realised that I shouldn't be wasting time on cruddy workarounds, no matter how interesting.

BlueHost offered a well-priced package that allowed (and still allows) unlimited domains on one plan with plenty of bandwidth and disk capacity. At the time, few hosting companies did this at a tolerable price. It is more common now.

This was exactly what I needed. Plus, it came with other useful features such as cron jobs, giving the ability to run admin scripts at scheduled times.

I chose BlueHost after reading many good things written by its customers. That was years ago and my experience over time remained generally good. I moved all my websites to the one account and the best part of a decade rolled by. The service suffered the odd glitch, but not often enough to make me want to move.

BlueHost grew enormously in the meantime and of course you can find some customer horror stories if you look. How many large companies do not? I can't tell you how BlueHost stacks up on average against its rivals, only that based on my experience, I'd probably still be there if things hadn't changed with me too.

Finally(?) a VPS… then two!

I ran Luxartis for a few years before selling it. The business is still operating in the hands of a husband and wife team, one of whom is a professional artist selling the tools he uses himself. If you want quality watercolour brushes, please check them out.

I shifted back into IT, learnt a lot more about Linux and got involved in another venturette. This one needed a dedicated server. VPS had become more affordable and what's more, I felt ready for one and was keen to go.

A toe in the digital ocean, then swimming in it

So I hired a VPS from DigitalOcean. That's an affiliate link which pays me a commission if you sign up through it and stay with DigitalOcean for a while, and gets you $10 in credits when you add a valid payment method. I would not endorse DigitalOcean if my experience hadn't been very postitive.

I spent time developing a web site there and it worked well in terms of quality of service and performance. I decided to move all my other sites to a second DigitalOcean VPS, or Droplet as the company calls them.

A VPS offers ultimate flexibility. I greatly value that. But it also gives me responsibilty for just about all the tech necessities that a shared hosting provider takes care of behind the scenes.

That requires an investment in time, particularly if you're running Linux and need to acquire the necessary skills. It isn't just about getting stuff to work (not always easy if you're new to it). That's just the start. Building a secure system is the main thing.

Warning: serious paranoia ahead. My excuse is that I can prove they really are out to get me.

I guarantee that within minutes or hours of creating a VPS, scum from around the planet will have their robots hammering at the doors and windows wanting to gain control. So proceed with caution if you go the VPS route.

If server admin isn't your game, do a lot of reading first. And then don't do anything critical for a while – like storing customer data or presenting the public face of your company. It won't look good if you get hacked, robbed and defaced soon after. Let the server sit for a while and see what happens to it.

Linux and the common main programs are reasonably secure out of the box, provided you choose sensible log-in options such as complex passwords and SSH access. However, they are not bomb-proof and as you start adding and changing things, the more you need to be aware of vulnerabilities and risks.

Watch and wait

Monitor server logs (at least for web server, mail server and authentification) to see the bad guys trying to get in, and use that as a prompt for more reading about anything you don't understand.

Like, why are people visiting your site trying to load pages from another site you haven't heard of? Are they succeeding? Are they likely to? Point to the server configuration and log entry lines that back up your answer. You are getting a huge number of system and mail login attempts. Are they succeeding? Are they likely to? How do you easily get alerted to a successful attack? What measures can you take to harden your defences?

Read about general system security, SQL security, web server security, mail system security. Read about good and bad practice in all the exposed stuff that you may be deploying, especially if you are writing it yourself.

Are you aware of SQL injection, script injection, mail header injection? Will you be storing user passwords? If so, do know the rudiments of good practice? Do you know about plain text and encrypted connections? Do you know the dangers of roll-your-own encryption schemes (your own or in other bits of code pasted from the internet)? Single-channel versus dual channel authentification? Checking which ports are open and closing ones that shouldn't be?

There are so many angles, though not all of them are relevant to everyone. And some apply whether you are working with shared hosting or your own server.

After a while, you will gain confidence that you are reasonably hack proof. But still assume that you will be hacked, because no system is perfect and users can be tricked. Design any software you create to minimise the consequences.

And keep on top of what's happening with your server and security in general. I saw hackers trying to exploit Shellshock the day after it was announced. Fortunately I had patched before they arrived.

So a VPS is another journey and one that needs to be taken more seriously than shared hosting. Perhaps I have overdone the paranoia but it is better to be that way than too lax. Anyway, it's an excellent learning experience in return for the effort it takes.

Multiple sites with ISPConfig

Setting up a Linux server involves a lot of typing and digging around in documentation and configuration files. My first VPS was set up manually. Parts of the process were particularly vexing for a first-timer, particularly getting to a secure working Postfix / Dovecot installation with virtual mailboxes. I learnt a lot in return for a big downpayment in time, persistence and frustration.

Second time round, I had a far better idea of what I was about, but needed quicker results in a slightly more complex scenario. The first VPS hosts a single web-based application and mail server. The second would host several sites, some of them for other people.

I needed to start thinking of myself as a mini web hosting provider.

Maintaining that from the command line on an occasional basis did not feel like an appealing idea, and is certainly unsuitable for third parties to interact with.

Luckily, I stumbled across an open source system called ISPConfig. It is the type of control panel software that you are faced with when you log into a web hosting account, with client, reseller and admin modes that enable you set up clients, sites, email accounts, FTP accounts and so on. Clients then control some features of their accounts as I did when I was with BlueHost.

I haven't explored it fully, but so far it has been a huge time saver. Installation took a couple of hours and is best done on a virgin Linux VPS (my preference is Ubuntu but ISPConfig supports other distros).

Follow their extensive but comprehensive HowToForge instructions. I had some minor issues at the start but experience setting up my first VPS enabled me to push through fairly easily. Because of that, and becuase it is always necessary to have some understanding of the underlying mechanics, I recommend going through the pain of a manual setup at least once even if you end up using ISPConfig or something comparable.

Be aware that the anti-virus component, ClamAV, needs a machine with 1Gb memory or it won't start. Even with 1Gb, as I load the server with more sites and email accounts, some of which are spammed horrendously, there are hints that I may need more. Perhaps I will end up with 2Gb of memory, or taking the mail server to a Droplet of its own. In the meantime, I added a swapfile to my Droplet to stop it falling over completely. Instructions for checking if your Droplet has a swapfile, and how to add one, are given here

Enough. I am very pleased with the resulting system. ISPConfig enabled me to migrate several sites and email accounts to my VPS over a day or so, and looks like a great platform for monitoring, control and further progress.

Professional services

I offer professional services in software development, databases, data manipulation and writing. Find out more at IanSharpe.com.

OFFER - Get $10 to spend on a DigitalOcean VPS

IanSharpe.com and other sites I manage are hosted at DigitalOcean. I am happy to recommend this company for Linux VPS hosting.

I get a commission if you open an account through this link and stay a while. DigitalOcean will credit $10 when you add a payment method. That gets you a generous slab of Linux-based VPS hosting for nothing and helps support this site.

All material © 1986–2015 Ian Sharpe. Nothing may be reproduced or made available for download elsewhere without permission