In this post, we will explain what a dedicated server is and the differences between a managed dedicated server and a fully managed dedicated server. At the expense of confusing you, a managed server being offered at Company A might not feature the same service level as a managed server offered at Company B. Why so? Read on to find out.

Before we delve into the differences, know that UNIXY (http://www.unixy.net) is a fully managed dedicated server hosting provider. We clearly state that our Linux server management service covers everything one would ever need. Our management philosophy is unambiguous: if you cannot complete a task with a few mouse clicks, UNIXY will gladly do. We secure, optimize, and monitor your server at all times throughout the year. We are always happy to help our clients and give them the support they need to thrive and stay worry-free.

• What is a server?

First things first, a server is a specialized computer that is installed at a private facility called a data center. The lingo used in the hosting business for “installed” is racked up. A data center is a private building built to withstand harsh environmental conditions, secured to fend off any kind of physical intrusion, configured with redundancy at the network and power grid level, and staffed with technicians, engineers, and security officers. Data centers are generally boring from the outside but very interesting in the inside. They sport state-of-the-art equipment and technology. The picture below is of a Google data center.

Outside View of a Data Center

• What is a dedicated server?

A dedicated server is a computer server that is racked up and configured to handle the requirements of an individual or an entity. It is said to be dedicated because its resources are not shared with any other entity. They are dedicated. At a bare minimum, the provider is required to install an operating system like Linux and replace any hardware component that fails while you are renting the dedicated server. This means that if your hard drive has a defect, you are entitled to a speedy replacement at no charge to you. The same applies to the network. Should you notice network connectivity issues, your provider is required to investigate and identify the root cause, again, at no charge to you.

Server Cabinet Inside a Data Center

• Is a control panel enough to manage a server?

Keep in mind that while a control panel is convenient and practical, one still needs trained engineers and technicians to maintain the back-end of the system. This is where server management comes in. At a bare minimum, server management should include system patching (software fixes and upgrades), system security enforcement to prevent compromises, and trouble shooting. So a control panel is a step forward in the right direction but is not all encompassing.

• What is a managed dedicated server?

A managed dedicated server is a dedicated server that comes with a certain level of support from the provider. Software upgrades and patching is provided for free. Software crash root cause remediation is also covered. The security of the server is assumed by the provider. Should you need help with installing common software on the server, that will also get taken care of. That includes a Web server software anddatabase software. The provider expects you to have a certain technical knowledge and understanding so you can navigate around the system. For example, they expect you to know how to add email accounts, add Web sites, transfer your content via FTP, and generally have a basic understanding of Web hosting.

• What is a fully managed dedicated server?

This is the creme of the crop of all management plans. If you rent a fully managed dedicated server, you, as a customer, are not to be concerned with anything beyond updating your Web content and running your business. Full management means that regardless of the request, the provider will complete it for you. Keep in mind that software development or software bug fix requests are not covered under this level. Those requests are meant to be handled by a software development firm.

• Server management is perceived differently

Server management tasks are not industry standard so there is ambiguity as to what plan covers what exactly. Some managed providers refuse to complete a certain request because the software is not covered. Others charge for the labor required to complete the task. As a consumer, it is always recommended to approach the provider, before signing up, and ask for what is or what is not covered by the managed service. Keeping a record of such conversation can protect you should you be in a such situation.

That’s all folks! This concludes our article on server management. I hope you enjoyed it.

In this article, we shall outline the steps required to build a private Content Delivery or Distribution Network (CDN) using Varnish Cache and Nginx. The goal is to build a CDN using free, readily available software but most importantly spend the least amount of funds possible. To this end, all nodes participating in this network are going to be virtual machines (Xen, Virtuozzo, OpenVZ, etc). Should you have any questions or comments on the configuration of this CDN, please post them in this forum: http://www.varnish-cache.info/

Our global CDN can not only keep the latest copy of static files closer to our global visitors but can also cache the most used pages (dynamic or not) in memory on the edge nodes! This means less trips to the geographically distant and slower Dynamic Node (see below). This is similar to what Akamai and other well known firms do, only at a fraction of the cost. However, in this article, and to keep things simple, we will only be caching static files.

Some of you might be surprised to learn that we built this global CDN free of charge for one of our beloved customers. UNIXY offers truly fully managed dedicated servers and clusters. Our motto is simple: what you cannot do with a few mouse clicks, we will gladly do it for you! Please visit us online when you have a chance: http://www.unixy.net. Please do ask if you have any question or comment. No question is minor!

• The Big Picture

The illustration below presents a logical layout of our CDN. Edge nodes can be located just about anywhere in the world. One could also add more nodes at any location should there be a capacity need. The Dynamic Content Node will typically run a mixture of MySQL, Apache, and server-side software built using PHP, Ruby, Python, .Net, or any language for that matter.

Global CDN

Nginx is a lightweight high-performance Web server that is able to handle large traffic consistently. We are leveraging its proxy and caching capabilities. We shall compile Nginx and leverage the proxy module. This module allows us to cache data on the local disks of the remote edge locations.

As its name implies, Varnish Cache is a high-performance caching engine used to keep recently accessed content in memory for fastest access. Varnish is not a Web server. Hence our need to bundle it with Nginx, which is acting as a Web server at the edge nodes. We will cover Varnish in detail in our next installment.

And finally the glue that holds all of these components together: BIND. BIND is the DNS software used to map Internet host names to IP addresses. We shall patch Bind to add geographical filters support. In other words, BIND will serve each client the IP of closest edge node in the CDN. For example, an vistor from Africa will receive the edge node IP of South Africa or Morocco depending on the filters. We will touch on this later.

At a minimum, we will need two nodes to demo and build our private CDN. That’s one Dynamic Content Node and one Edge Location node. The Dynamic Content Node will run the full LAMP stack along with BIND and the geographical filters patch. The Edge Location node will run Nginx and Varnish. One could always run BIND+GeoIP on a separate node as it is good practice. We will assign the hostname dynamic_content to the Dynamic Content Node and edge_node to the Edge Location.

Download BIND from ISC: http://www.bind9.net/download

Download MaxMind’s C API: http://geolite.maxmind.com/download/geoip/api/c/

[root@dynamic_node /]# cd /usr/src/

[root@dynamic_node src]# wget http://mirrors.24-7-solutions.net/pub/isc/bind9/9.2.4/bind-9.2.4.tar.gz

[root@dynamic_node src]# wget http://geolite.maxmind.com/download/geoip/api/c/GeoIP-1.4.6.tar.gz

[root@dynamic_node src]# tar -xzvf bind-9.2.4.tar.gz

[root@dynamic_node src]# tar -xzvf GeoIP-1.4.6.tar.gz

[root@dynamic_node src]# cd GeoIP-1.4.6

[root@dynamic_node GeoIP-1.4.6]# ./configure –prefix=/usr/local/geoip

[root@dynamic_node GeoIP-1.4.6]# make

[root@dynamic_node GeoIP-1.4.6]# make install

[root@dynamic_node GeoIP-1.4.6]# cd ..

[root@dynamic_node src]# patch -p0 < bind-9.2.4-geodns-patch/patch.diff

[root@dynamic_node src]# cd bind-9.2.4

[root@dynamic_node bind-9.2.4]# CFLAGS=”-I/usr/local/geoip/include” LDFLAGS=”-L/usr/local/geoip/lib -lGeoIP” ./configure –prefix=/usr/local/bind

[root@dynamic_node bind-9.2.4]# make

[root@dynamic_node bind-9.2.4]# make install

[root@edge_node src]# wget http://nginx.org/download/nginx-0.8.45.tar.gz

[root@edge_node src]# tar -xzvf nginx-0.8.45.tar.gz

[root@edge_node src]# cd nginx-0.8.45

[root@edge_node nginx-0.8.45]# ./configure –prefix=/usr/local/nginx –with-http_realip_module

[root@edge_node nginx-0.8.45]# make

[root@edge_node nginx-0.8.45]# make install

http {

include       mime.types;

default_type  application/octet-stream;

sendfile        on;

keepalive_timeout  65;

upstream dynamic_node {

server 1.1.1.1:80; # 1.1.1.1 is the IP of the Dynamic Node

}

server {

listen       81;

server_name  cdn.unixy.net;

location ~* \.(gif|jpg|jpeg|png|wmv|avi|mpg|mpeg|mp4|htm|html|js|css|mp3|swf|ico|flv)$ {

proxy_set_header  X-Real-IP  $remote_addr;

proxy_pass http://dynamic_node;

proxy_store /var/www/cache$uri;

proxy_store_access user:rw group:rw all:r;

}

[root@edge_node src]# wget http://downloads.sourceforge.net/project/varnish/varnish/2.1.2/varnish-2.1.2.tar.gz?use_mirror=cdnetworks-us-1&ts=1279434397

[root@edge_node src]# tar -xzvf varnish-2.1.2.tar.gz

[root@edge_node src]# tar -xzvf varnish-2.1.2.tar.gz

[root@edge_node varnish-2.1.2]# ./configure –prefix=/usr/local/varnish

[root@edge_node varnish-2.1.2]# make

[root@edge_node varnish-2.1.2]# make install

• Wrap up

The instructions above can replicated across however many additional Edge Nodes you want to add. One could also add redundancy to the BIND+GeoIP setup by configuring secondary nodes. The illustration below shows the flow of a request from top to bottom.

CDN Request and Response Flow

That’s all folks! I hope you enjoyed this article.

SpamAssassin (SA) is a program used for email spam filtering based on content matching rules. The Bayesian classifier that comes with SpamAssassin can be trained to recognize spam (or ham) based on a few sample emails. SA breaks the spam email into tokens or group of tokens for processing. Once SA is fed a large enough sample of spam tokens, it will start marking spam email with a higher score and thus block the spam. The same applies to ham except that the score is lower.

The sa-learn utility that comes with SA is the tool used to train SA on what is spam or what is ham. It is crucial to feed sa-learn with either spam or ham and not both at the same time. While sa-learn has several command line switches for various options, one only needs a couple of flags to have it process emails. The following two command lines are all one needs to get the job done:

To train SA on spam, run the following from the server in question:

sa-learn --showdots --mbox --spam spam-file

To train SA on ham, run the following from the server in question:

sa-learn --showdots --mbox --ham ham-file

spam-file and ham-file are files in Mailbox format. So what if your inbox is of type Maildir? There is an extra step involved in converting the Maildir format to a Mailbox. The utility mb2md can do the job seamlessly. Once the Maildir is converted to Mailbox, simply replace ‘spam-file’ in the command line above with the resulting Mailbox file from the conversion.

That’s all folks! We hope this was useful.

Depending on which version of Varnish you have running, there is a chance the code is still experimental and the whole Varnish daemon is prone to a fatal crash.

Here is a quick and dirty monitoring script for Varnish. It essentially runs as a crontab job and requests a PING response. Should it not receive a PONG from Varnish, it will attempt a restart. There is a second round of testing within the same script. This is a second level of PING request; just in case. Be sure to set the usual defaults like -T port and varnish runlevel script.

#!/bin/bash

result=$(echo -e "ping\n\r" | nc localhost 6082|grep PONG|wc -l);

if [ "${result}" -lt "1" ];
then
/etc/init.d/varnish stop;
sleep 5;
/etc/init.d/varnish start;
echo "$(hostname): Varnish restart" | mail -s "$(hostname): Restarting varnish" alerts@example.com;
fi

sleep 5;

results=$(echo -e "ping\n\r" | nc localhost 6082|grep PONG|wc -l);

if [ "${results}" -lt "1" ];
then
/etc/init.d/varnish stop;
sleep 5;
/etc/init.d/varnish start;
echo "$(hostname): Second Varnish restart" | mail -s "$(hostname): Restarting varnish second time" alerts@example.com;
fi

exit 0;

Finally load the job into crontab:

*/5 * * * * /root/varnish.sh

A cleaner way of accomplishing the same goal would be to establish a permanent connection to the Varnish admin port (6082 in this case) and issue a PING command every other second or so. The interval can be in the sub seconds as opposed to minutes as is the case with crontab.

Here is an example:

# telnet localhost 6082
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ping
200 19
PONG 1274931430 1.0
ping
200 19
PONG 1274931434 1.0
ping
200 19
PONG 1274931437 1.0
ping
200 19
PONG 1274931443 1.0

We deploy Varnish and other tools on our clients’ server to get the most performance out of hardware. Our clients are happy with the performance boost and we are happy of the end result. Please do get in touch if you have any question or comment

That’s all folks!

Spamd is one the highest resource consumer on a cPanel server. It allocates a lot of memory from the get-go and holds on to it throughout. There is a way to limit the number of spamd processes that are spawned. On a cPanel server, which is what this guide covers, there is a configuration file called /etc/cpspamd.conf with the following lines:

maxspare=1
maxchildren=3

For a leaner server. we recommend dropping maxchildren to 1 and maxspare to 1. This will save a good hundred of megs of memory. Don’t forget to restart exim for these changes to take effect.

I hope this tip is useful. That’s all folks!