How To Set Up Clustered Nameservers With cPanel

As important as DNS is to web hosting, it is a good idea to make it redundant when possible. If you have two or more cPanel servers, you can use cPanel’s DNS clustering to lower the risk of a DNS failure on a nameserver taking down all of your sites. Here’s how to set that up:

Step One: Enable Clustering For Each Server

First, click over to Configure Cluster in WHM on each server. In the Modify Cluster Status box, select Enable DNS clustering. Click the Change button.

Step Two: Configure The Primary Nameserver

On the first server, scroll down to Add a new server to the cluster. The type will be cpanel. Click Configure. This will take you to the cPanel DNS Remote Configuration page.
In Remote cPanel & WHM DNS service, put the hostname or IP address of the second nameserver. Next, in Remote server username, put the username of the nameserver. While this can sometimes be reseller, in most cases it will be root.

In the next area, Remote server access hash, you will need to put the ssh public key of the other server. To find that key, go to the Manage root’s SSH Keys page in the second server’s WHM. Click Generate a New Key. On the next page, leave the password blank and click the Generate Key button. cPanel will issue a warning about the security of an SSH key without a password, but unfortunately it is needed for this sort of automation. (It is only a security risk if someone gains root access to your server, by which point your server’s security will already have been compromised.)

Still on the second server, click back to Manage root’s SSH Keys. Then click View/Download Key under the Public Keys: heading. This will take you to the key which you will then copy back to the first server, in the Remote server access hash field.

Uncheck the Setup Reverse Trust Relationship checkbox.

Set the DNS role of the server to Write-only. Click Submit.

Step Three: Repeat Step Two, Only Backwards

Step Three is going through the same process as Step Two, only reversing the servers. Also, role of the server should be set to Standalone instead of Write-Only.

Adding DNS Zones

There is one quirk of this system: DNS zones for domains will have to be added on the Write-Only server. So when creating cPanel accounts on the Standalone server, make sure to add the DNS for the domain to the Write-Only server.

===

Kloxo Useful SSH Commands

For those of you who have opted for the free Kloxo control panel on your VPS or dedicated server, here
are some common, and simple, commands you can use to make your life easier.

As with anything free, Kloxo has a few bugs any sys admin will run into. Even the big commercial packages, like cPanel, have annoying bugs.
Rather than banging your head against your keyboard for hours on end, I have complied a list of the most commonly used, and simple, command line fixes for Kloxo.

Websites fail to load:
/script/fixweb

DNS Fails to resolve:
/script/fixdns

Horde Mail gives 500 internal server errors:
/script/fixhorde

Email, in general, just does not function:
/script/fixmail

Kloxo fails to load, don’t reboot, just run:
/script/restart

While these are the most common, there are also many more /script commands.
Be careful with what you run from /script – some can have nasty consequences, if not used properly.
If in doubt, please visit the support forums at http://lxcenter.org. Always log into your VePortal and create a
backup of your VPS container, before running any system wide command you are not familiar with. Allow time
for the backup to complete, before running the commands.

Ten SEO Mistakes Made on Database Driven Websites

Search engine friendly websites is one of those often heard phrases, both from web site development companies and from their clients. Everyone knows that this is important to have, and yet it is one of the things that is actually often overlooked.

Search engine optimisation companies actually spend a lot of their time analysing a website and removing barriers to the search engines ranking a site highly. At the web development level, it is possible to build a site that is perfectly search engine friendly. One of the hardest types of sites to get right though are database driven websites. Listed below are ten of the most common issues that are created, often unknowingly, in the development process of a dynamically generated web site.

1. Pages with duplicate content – not enough differential areas within the pages, so that only small areas of the page change from page to page. It is essential that enough of the page text changes for the search engines to see an appreciable difference between one page and the next.

2. Pages with duplicate page titles – the page title is a great indicator to the search engines of the primary content of the page. Whilst this is often unique on sites such as e-commerce websites, it is often overlooked in other sites, particularly where small areas of the site are generated from a database, such as news pages.

3. Pages with duplicate meta descriptions – again, this is easy to overlook and set a global or category level meta description. These give the search engines a reason to penalise your site for not giving them enough information, and again, creating a unique meta description for every page is an essential SEO task.

4. Using auto-generation of pages as a shortcut instead of creating good content. This is linked quite closely to point 1, where it is possible to create pages that have only a tiny percentage difference between them. Databases are fantastic ways of storing information, but you still need to put the work in to fill them with content. Unique information about the subject of the page will immensely help both the long tail and the ability of the search engines to determine that a page is valuable.

5. Creating pages that are hidden behind form submissions or javascript postbacks that cannot be accessed by a search engine crawler. This is far more common that is generally realised. For instance .NET creates postback links by default instead of proper links – potentially making huge sections of a site unreachable. Likewise, it is easy to hide lovely content rich areas of your site behind a drop down selector in a form that means certain areas of the site are not visible.

6. Too many query strings – this is a common bugbear of the professional SEO, where complicated database selections create deep levels of pages, but with seven or eight &id= type strings. Additionally, some bad development methodology can leave pages with null query strings that appear in every URL but don’t do anything. The answer to this is generally URL rewrites, creating much more search engine friendly and user-friendly URLs!

7. Putting query strings in different orders when accessed through different places – this can create duplicate content issues, which can cause major penalties.

8. Not using user language to generate automated pages – if you are going to create a database driven website that uses words in the query strings (or better in rewritten URLs) make sure that you use words that will help you with SEO – if you sell widgets, make sure you are using the word widgets somewhere in the URL instead of just product= or id= – keyword research can assist with this.

9. Not allowing the meta data and title to be edited easily after the site build. It is possible to hardcode the generation of meta information into a database that doesn’t allow it to be edited later. Creating a mechanism for modifying this information initially helps everyone at a later stage when the information needs changing without shoehorning it into an already developed structure.

10. Creating keyword stuffed pages by using auto-generation. Once upon a time, search engines quite liked pages with high densities of your keywords, but now these are likely to get you marked down rather than up. So be aware when creating pages that long pages with lots of your products on can create too high a density. For instance listing blue widgets, light blue widgets, navy blue widgets, sky blue widgets is going to create a page with a very dense page for the phrase “blue widgets”.

These are just 10 of the most common potential optimisation pitfalls when creating dynamic websites. There are many more facets to producing a great database driven site, including user friendliness, speed, performance and security, but they all add together to make the best solution to your needs.

About the Author: Mark Stubbs is a freelance writer who specialises in internet marketing and web site development. For more information on database driven websites he suggests that you visit www.obs-group.co.uk.

Source

How To Increase Page Load Speed with Apache KeepAlive

The KeepAlive directive for Apache allows a single request to download multiple files. So on a typical page load, the client may need to download HTML, CSS, JS, and images. When KeepAlive is set to “On”, all of these files can be downloaded in a single request. If KeepAlive is set to “Off”, each file download would require it’s own request.

You can control how many files can be downloaded in a single request with the MaxKeepAliveRequests directive, which defaults to 100. If you have pages with a lot of different files, consider putting this higher so that your pages will load in a single request.

One thing to be cautious of when using KeepAlive, is the connections will remain open waiting for new requests once the connection is established. This can use up a lot of memory, as the processes sitting idly will be consuming RAM. You can help avoid this with the KeepAliveTimeout directive, which specifies how long the connections remain open. I generally put this below 5, depending on the average load times of my site.

An important factor when deciding to use KeepAlive is the CPU vs. RAM usage requirements for your server. Having KeepAlive On will consume less CPU as the files are served in a single request, but will use more RAM because the processes will sit idly. Here is an example of KeepAlive settings I use:

KeepAlive             On
MaxKeepAliveRequests  50
KeepAliveTimeOut      3

Once KeepAlive is on you can see the following header in your server’s response:

Connection:  Keep-Alive


How To Increase Page Load Speed with Apache mod_deflate

Apache’s mod_deflate is an Apache module that will compress output from your server before it is sent to the client. If you have newer version of Apache the mod_deflate module is probably loaded by default, but it may not be turned on. To check if compression is enabled on your site, first verify that the module is loaded in your httpd.conf file:

LoadModule deflate_module modules/mod_deflate.so

Then you can use to following web based tool to verify compression:

http://www.whatsmyip.org/http-compression-test/

For my server, CentOS 6.x, the module was loaded by default but compression was not on until I set up the configuration file. You can place your compression configurations into your httpd.conf file, an .htaccess file, or a .conf file in your httpd/conf.d directory. My base configuration file is as follows:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain 
    AddOutputFilterByType DEFLATE text/css 
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE text/xml
</IfModule>

The configuration file specifies that all the html, plain, css, and javascript text files should be compressed before being sent back to the client. When writing your configuration file, you don’t want to compress the images because the images are already compressed using their own specific algorithms and doubling compression just wastes CPU. Depending on the server you are running, you may want a more comprehensive compression schema based on different file types and browsers. More information can be found in the below referenced Apache docs.

Another thing to consider is that while the gzip compression algorithm is fast and efficient for smaller text files, it can be cumbersome on your CPU when trying to compress larger files. Be wary when adding compression to non text files > 50 KB.

When you examine the HTTP headers of your server’s response, you will see the following headers for compressed content:

Content-Encoding: gzip
Vary: Accept-Encoding

Here is another default configuration file taken from Ubuntu 12.10:

<IfModule mod_deflate.c>
    # these are known to be safe with MSIE 6
    AddOutputFilterByType DEFLATE text/html text/plain text/xml    # everything else may cause problems with MSIE 6
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/x-javascript application/javascript 
    AddOutputFilterByType DEFLATE application/ecmascript
    AddOutputFilterByType DEFLATE application/rss+xml
</IfModule>

Reference
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html