PHP INI Directives Per Directory

PHP

We recently searched high and low for an elegant way to define PHP directives on a per domain basis. We use Lighttpd web server, and therefore .htaccess rules and configurations are unavailable. The reason for the requirement of granular PHP directive settings, is we have clients that want to host multiple web applications on a single cloud server, but want PHP to perform slightly different for each of their applications. A concrete example of this is, a PHP application may be quite old, and require register_globals on (we know, this is bad practice and we frown upon it), while the rest of the clients applications can have register_globals off. Another great example for us internally, is to be able to define a PHP log file for each domain independently, instead of a single monstrous PHP log file for the entire cloud server.

PHP user ini files to the rescue! User PHP ini files allow you to define PHP directives on a per directory basis, which is extremely powerful and flexible. The only caveat is that you must be running PHP 5.3.0 or greater. To get user php ini files running simply modify your main/base php.ini file and add the following two directives:

user_ini.filename = .php.user.ini
user_ini.cache_ttl = 60

The first directive, user_ini.filename specifies the file name that PHP searches for in each directory to process PHP directives. If set to an empty string, PHP doesn’t scan at all. The default is .user.ini, we prefer .php.user.ini, but you may use whatever file name structure you wish. The second directive user_ini.cache_ttl controls how often user INI files are re-read. The default is 300 seconds (5 minutes), but we prefer a slightly faster refresh, so our user_ini.cache_ttl is 60 (1 minute).

Once the above two directives are in your main/base php.ini, simply create your user ini files, and put whatever PHP directives you want to override in the files. You may have to wait up to user_ini.cache_ttl for your custom directives to take effect, but you will NOT have to restart your web server; wooo hoo!

If you have any questions or further comments, don’t be shy; let us know.

How To Migrate Linux Servers Across Cloud Providers

619Cloud - Personalized Cloud Hosting - Managed Virtual Private Servers
We wrote a shell script to assist in migrating an entire Linux CentOS 5.X server. The script should work with most Red Hat based Linux distributions such as Fedora, but we have not officially tested it. The shell script can be used to move a server instance to a different physical server, or even move a server to a completely new data center or provider. We recently tested our script by moving a server instance of CentOS 5.5 x64 on Slicehost to Rackspace Cloud Servers successfully. It should also work migrating to Linode or Amazon Elastic Compute Cloud. Please leave comments, if you successfully migrate to Linode or Amazon EC2, we would love to know.

The script takes the entire source server and rsyncs everything that is important, to a destination server, excluding certain naughty directories such as /boot, /proc, /sys, /tmp, and /dev which should not be transferred. Make sure the destination server is a completely fresh install of the exact same operating system as the source. Also, the source and destination servers should be running the exact same kernel version, or else you may experience strange things like “Could not load /lib/modules/SOME-KERNEL-VERSION/SOME-MODULE-NAME”. The script automatically handles housekeeping such as installing rsync on both the source and destination servers. It also attempts to stop services on the source that should not be running when rsyncing to provide a consistent snapshot. You may modify the services the script stops on the source, currently it handles all the major popular services; Lighttpd, Apache, Nginx, MySQL, PostgreSQL, ProFTP, and Postfix.

The script tries its best to not copy any of the network configuration, but we found that one file must be modified on the destination once the rsync has completed. You must modify the gateway address in the file /etc/sysconfig/network on the destination server to the proper default gateway BEFORE REBOOTING. Once that is complete, simply reboot the destination server, and you should be completely migrated successfully.

Here is the script for everybody to use and enjoy. Simply copy it to your source server and run it with: sh migrate_server.sh. Let us know in the comments or shoot us an e-mail if you have any questions/comments or if you discover any bugs or weirdness. Also, if you’re feeling ambitious to port the script to other Linux distributions, such as Ubuntu please let us know, we will post ported scripts.

[Download Shell Script]

migrate_server.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
#!/bin/bash
# @Description Migrate A CentOS 5.X Server
# @Usage Copy to the source server and run with: sh migrate_server.sh
# @Version 1.0.2
# @Date Last Modified 08/07/2010
# @Author 619Cloud <http://www.619cloud.com> <hello@619cloud.com>
# @Copyright (c) 2010 619Cloud. All Rights Reserved.
 
# @Returns success or failure
function is_root_user() {
	[ $(id -u) -eq 0 ] && return 0 || return 1
}
 
# @Returns text and if not root user exits with code 1 (error)
function require_root_user() {	
	if is_root_user
	then
		echo "Are We Runnning As Root? [ Yes ]"
	else
		echo "Are We Running As Root? [ No ]"
		echo "Fatal Error: You must be logged in as root to execute this shell script."
		exit 1
	fi	
}
 
require_root_user
 
read -p "Provide the destination server IP address or hostname: " destination_ip_address
 
echo -e "\n"
echo "##########################################################################"
echo "###   WHEN PROMPTED, PROVIDE THE DESTINATION SERVERS ROOT PASSWORD.    ###"
echo "##########################################################################"
echo -e "\n"
 
#Install rsync on the destination
ssh root@$destination_ip_address yum -y install rsync
 
#Make sure we were able to ssh successfully
rc=$?
[ "$rc" = "255" ] && exit 1
 
#Install rsync on the source
yum -y install rsync
 
#Yum clean all on the source, to free up some disk space
yum clean all
 
#Create the rsync_excludes file on the source
echo -e "/boot\n/proc\n/sys\n/tmp\n/dev\n/etc/fstab\n/etc/resolv.conf\n/etc/conf.d/net\n/etc/network/interfaces\n/etc/sysconfig/network-scripts/ifcfg-eth*" > /rsync_excludes.txt
 
#Stop critical services on source
for i in lighttpd httpd nginx mysqld postgresql proftpd postfix
do
	#Set rc equal to status code
	service $i status 2>/dev/null
	rc=$?
 
	#If status equals 0, we know its running, and can stop it
	[ "$rc" == "0" ] && service $i stop
done
 
echo -e "\n"
echo "##########################################################################"
echo "###   WHEN PROMPTED, PROVIDE THE DESTINATION SERVERS ROOT PASSWORD.    ###"
echo "##########################################################################"
echo -e "\n"
 
#Do the rsync
rsync -avz --delete --exclude-from=/rsync_excludes.txt / root@${destination_ip_address}:/
 
#Make sure we were able to login successfully
rc=$?
[ "$rc" = "255" ] && exit 1
 
echo -e "\n"
echo "##########################################################################"
echo "###   WHEN PROMPTED, PROVIDE THE DESTINATION SERVERS ROOT PASSWORD.    ###"
echo "##########################################################################"
echo -e "\n"
 
#First we have to clear the source known_hosts file
echo > ~/.ssh/known_hosts
 
#Delete the rsync_excludes.txt file on the destination
ssh root@$destination_ip_address rm -f /rsync_excludes.txt
 
#Complete
echo -e "\n"
echo "########################################################################"
echo "#                          ! VERY IMPORTANT !                          #"
echo "# You MUST go into the destination server and modify the network file. #"
echo "#  The destination GATEWAY ADDRESS must be updated before you reboot.  #"
echo "#                                                                      #"
echo "#                     Modify /etc/sysconfig/network                    #"
echo "#                                                                      #"
echo "# Update the gateway address to the proper destination server address. #"
echo "#                                                                      #"
echo "#  AGAIN, THE DESTINATION GATEWAY ADDRESS MUST BE UPDATED BEFORE YOU   #"
echo "#  REBOOT. FAILURE TO DO THIS, MAY RESULT IN THE DESTINATION SERVER    #"
echo "#  BEING INACCESSIBLE.                                                 #"
echo "########################################################################"
echo -e "\n"
echo "########################################################################"
echo "### PLEASE --REBOOT-- THE DESTINATION SERVER TO FINALIZE MIGRATION.  ###"
echo "########################################################################"
echo -e "\n"
 
exit 0

Client Portal Updated

We are proud and excited to release our completely redesigned client portal.

The client portal allows our clients to view general information about all of their cloud servers in one centralized location. In addition, clients may view historical bandwidth figures for cloud servers in a graph, and even export bandwidth figures to a CSV file. Finally, if you ever need to reboot any of your cloud servers, you can do so from within the client portal.

Almost forgot; clients may also create and modify support tickets and update billing details in the client portal as well.

View Screen Shots

Servers | Reboot Server | Billing

Video Demonstration


619Cloud - Client Portal

How Twitter Uses BitTorrent To Deploy Code To Their Servers

A very interesting video from Twitter engineering’s Larry Gadea on how they use BitTorrent and Capistrano to deploy code and binaries to their thousands and thousands of servers in a matter of seconds.

You can even get the source code for this project on GitHub; http://github.com/lg/murder.

Twitter – Murder Bittorrent Deploy System from Larry Gadea on Vimeo.

Node.js – Server Sided Javascript

We recently stumbled across this great video from the creator of Node.js; Ryan Dahl, talking about what the project is, why it exists, and benefits of event server design over traditional threaded server design.

Node.js is all the buzz at the moment, and makes creating high performance, real-time web applications easy. Node.js is an evented I/O framework based off the Google V8 JavaScript Engine. It allows JavaScript to be used end to end, both on the server and on the client.

Ryan does an outstanding job explaining all the technical details, proving why event server design is superior, and even provides some working demonstrations and examples. We enjoy coding in JavaScript, and are really intrigued by the concept of server side JS. Perhaps Node.js will be the project that launches the server side JS revolution.

Want to lean more about Node.js? There is a great write-up and complete tutorial here.

Server Monitoring And Notifications

Server Monitoring And Alerts

Server Monitoring And Alerts

We are pleased to announce that we are now offering complete solution monitoring and notifications. Monitoring includes CPU usage, memory usage, swap usage, disk usage, network utilization, MySQL statistics, Apache statistics, and many other metrics, complete with e-mail and iPhone push notifications. The monitoring interface is all controlled and viewed within a beautiful web application, and there is even an iPhone app.

Pricing is $15 a month per cloud server, and is compatible with all of our solutions.

Monitoring Screen Shots

Dashboard | Graphs | Snapshot | iPhone App

Interested in learning more about our VPS server offerings? Click here to see our solutions and pricing.

WordPress is an amazingly powerful blog and website content management system. In fact, it is what we use. The only caveat is that it tends to be somewhat bloated and requires a bit of tweaking and custom solutions when the blog or website traffic increases. There have been countless times we have been browsing Digg or Reddit and a linked blog post or WordPress website is down because of the huge increase in traffic.

Our goal, is to provide five essential steps for keeping your WordPress blog and websites up. All of our steps relate specifically to server infrastructure, and don’t hit any of the other ways to optimize Wordprss itself with plugins or code modification; we’ll leave that to another blog post.

1lighttpd - fly light

Lighttpd Web Server Instead Of Apache

Lighttpd offers a small memory footprint compared to other web-servers, and superior performance when serving static content such as images, css, javascript and plain html files. In addition it has gained a large adoption rate and is used by several popular web 2.0 sites like YouTube, Wikipedia and Meebo. Server side requests such as PHP are passed off to fastCGI for processing. Lighttpd has a extensive library of plugins such as mod_rewrite, mod_redirect, mod_fastcgi, mod_expire, mod_compress, and mod_proxy.

Also, see our blog post (Lighttpd Web Server With WordPress Permalinks) on how to properly configure permalinks (mod_rewrite) on lighttpd for WordPress. It is a bit different than Apache.

2PHP: Hypertext Preprocessor

XCache PHP Caching

XCache is a fast, stable PHP opcode cacher that has been tried and tested. XCache accelerates the performance of PHP on servers. It optimizes performance by removing the compilation time of PHP scripts by caching the compiled state of PHP scripts into memory and uses the compiled version straight from the RAM. This will increase the rate of page generation time by up to 5 times as it also optimizes many other aspects of php scripts and reduces serverload. We have tried other PHP opcode cachers such as eaccelerator, iconCube, and APC, but have found that XCache delivers the best performance results, and also is the simplest to install and configure.

3GZip

Enable Gzip Compression Of Static Content

Gzip is a popular and effective compression method. Most modern web browsers support and accept compressed data transfers. By gziping static content such as css, javascript, and html files, response times can be reduced by 60-70%. There is a nice guide on how to configure Gzip on lighttpd at: http://www.cyberciti.biz/tips/lighttpd-mod_compress-gzip-compression-tutorial.html

4InnoDB

MySQL Storage Engine InnoDB

Change all WordPress MySQL tables to use InnoDB storage engine instead of MyISAM. InnoDB is transaction-safe meaning data-integrity is maintained throughout the entire query process. InnoDB also provides row level locking, as opposed to table-locking, meaning while one query is busy updating or inserting a row, another query can update a different row at the same time. These features increase multi-user concurrency and performance.

Here is a quick script to update all tables in a database to the InnoDB storage engine.

mysql -p -e "show tables in PUT-DATABASE-NAME-HERE;" | tail --lines=+2 | xargs -i echo "ALTER TABLE {} ENGINE=INNODB;" > alter_table.sql
mysql --database=PUT-DATABASE-NAME-HERE -p < alter_table.sql

5MySQL - The world's most popular open source database

Tune MySQL

This is perhaps the most difficult step, because there inst a cut and dry approach. Often times it requires a bit of trial and error, and tweaking various configuration directives. No need to fret though, we have listed a full MySQL configuration file below. The directives in this configuration file are optimized for MySQL5 running WordPress on InnoDB tables. Additionally, the configuration file below is for a dedicated MySQL5 server with at-least 256MB of dedicated memory and four processors.

OBLIGATORY WARNING…Please don’t blindly copy the MySQL configuration file below into your server and restart MySQL without first doing a full backup, and understanding the implications of these changes. The last thing we want, is people hosing their MySQL databases.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# @author 619Cloud <http://www.619cloud.com> <hello@619cloud.com>
# @copyright (c) 2010 619Cloud. All Rights Reserved.
 
# Optimized for a dedicated MySQL5 server with at-least 256MB of dedicated
# memory, four CPUs, running InnoDB storage engine tables.
 
[mysqld]
skip-bdb
skip-ndbcluster
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-storage-engine=InnoDB
long_query_time=2
log-slow-queries=/var/log/mysql_slow.log
expire_logs_days=14
max_connections=50
external-locking
 
port=3306
net_retry_count=5
max_connect_errors=50
wait_timeout=3600
connect_timeout=15
 
open_files_limit=1536
key_buffer_size=64M
innodb_buffer_pool_size=128M
innodb_additional_mem_pool_size=8M
innodb_log_buffer_size=8M
group_concat_max_len=16k
max_sort_length=16k
max_length_for_sort_data=16k
query_cache_type=1
query_cache_limit=4M
query_cache_size=64M
innodb_thread_concurrency=16
thread_concurrency=16
thread_cache=128
thread_stack=1M
read_buffer_size=1M
join_buffer_size=2M
read_rnd_buffer_size=1M
table_cache=512
tmp_table_size=256M
max_heap_table_size=256M
innodb_log_file_size=128M
innodb_flush_log_at_trx_commit=1
innodb_file_per_table
log-warnings
 
user=mysql
old_passwords=1
 
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

If you have any additional questions, please leave comments below and we will reply.

Finally; want to let us professionally handle all the details and nitty gritty of keeping your WordPress blog or website up? Sure, no problem. We have a special wordpress solution based off two virtual private servers that has a discounted setup fee ($200) and does all the steps listed in this post, plus a plethora of additional tweaks and performance tricks guaranteed to keep your WordPress blog and website up and buzzing along.

» Read more about our WordPress hosting solution

Managed WordPress VPS Solution

Wordpress Managed VPS Hosting

We are happy to announce that we are now offering a special WordPress solution. The solution is based off of our SoHo solution and includes two virtual private servers. The first being the webserver, and the second a dedicated MySQL server. This approach allows us to scale the webserver and database server independently of each other, and also provides independent CPU and memory resources for each service. Of course, PHP 5, MySQL 5, and WordPress are installed, with a few extras such as a PHP caching engine X-Cache and using Lighttpd web server instead of Apache for performance. Finally, we install, configure, and optimized the W3 Total Cache plugin for you.

The setup fee for this solution is a special price of $200.00 instead of the normal setup fee of $300.00 for a SoHo solution.

Read more and sign up here.

Finally, check out our related blog post 5 Essential Steps For Hosting A Scalable WordPress Blog Or Website.

As always, if you have any questions or comments feel free to e-mail us.

Managed DNS Hosting

We are proud to announce, that we are now offering standalone managed DNS hosting. You can create as many DNS records as you like per domain. Additionally, there is no limit to the number of DNS queries a domain can receive. Our multicast DNS network provides three name servers, in geographically disperse locations providing exceptional fault tolerance and speed.

Simply, $5 a year / per domain.

We support A, CNAME, MX, NS, SRV, TXT (such as SPF), AAAA, PTR record types and allow customizable TTL (time to live) for each individual DNS record.

Sign Up For Managed DNS Hosting Now!

Page 1 of 212