Category: cPanel


So I pushed my changes to the production repository, only to discover that Memcache wasn’t installed on the server at work (a cPanel installation running over CentOS(6 i think)). Time to install it then!

in the terminal, get memcached installed. Nice n easy.

sudo yum install memcached

Then launch it!

memcached -d -u nobody -m 512 -p 11211 127.0.0.1

Then install memcache PHP extension. You do this in cPanels WHM. Search module installers in WHM

In Find a PHP Pecl, type memcache, and get it installed! You may or may not have to restart apache, but go to a phpinfo() and you should now see it running on your system!

See my previous post for how to use memcache in your PHP ūüôā

If you’ve been following these posts, we now have a lovely git push to deploy setup, and can ssh into our server without constantly needing to enter our password through the use of ssh keys.

However, if you’re running on cPanel, you will probably have bumped into this error:

SoftException in Application.cpp:256: File "/home/username/public_html/index.php" is writeable by group

This is clearly a permissions error, and so the obvious thought is to chmod it. However, we don’t want to ssh in and chmod every time we push! On the testing server, the permissions are fine, but they are different once the git push has done its post-update.

The reason for this is something to do with a thing called umask. Umask is a user mask which is created for processes that are performing tasks, and affects new files and folders.

The solution to this is to edit ~/.bash_profile, and insert the following command:

umask 022

From now on you shouldn’t have the problem. With newly created files.

To sort already existing files, Chmod -R 755 any folders affected, OR just log out and in, and git pull or git reset –hard HEAD^ in order to re-fetch the files. This time they should be created without any strange permission errors!

 

Without messing with cPanel or Apache’s setup, we can still install Varnish to cache our pages a lot quicker, via the iptables firewall!

The problem was that changing the apache httpd.conf didnt work as expected, as cPanel does a lot of auto generating and tweaking of system files. yuk. i much prefer a terminal any day. Anyway! Lets have a look:

yum install varnish
nano /etc/sysconfig/varnish

comment out configuration 1, 3, and 4, uncomment config 2 and set as follows:

DAEMON_OPTS = " -a :8080 \                                          
                -T localhost:6082 \             
                -f /etc/varnish/default.vcl \              
                -S /etc/varnish/secret \             
                -s malloc,256m"

The -a line is the port varnish will run on. In a normal configuration, Varnish will take over port 80, so make it port 80. In the case of a server using cPanel, if you cant change your apache port to 8080, then you can set varnish to 8080 instead.

nano /etc/varnish/default.vcl

backend default {
    .host = "127.0.0.1";
    .port = "80";
}

The backend is Apache. In a normal varnish setup, this port should be 8080.  Using a reverse system using iptables, apache stays as port 80. Also, the host should become the external IP in this configuration.

Now, depending on your setup, depends what happens next.

Without cPanel, under a standard setup, you will have set Varnish to port 80 and Apache to port 8080. In this case, you must edit your apache httpd.conf, searching and replacing :80 with :8080. Then just stop and start the services as below, skipping the iptables stuff.

With cPanel, we can leave that alone and instead use an iptable rule to send all port 80 requests to varnish at port 8080. Edit ~/.bashrc, pasting this in:

alias varnishon='iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080'
alias varnishoff='iptables -t nat -D PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080'
alias varnishstatus='iptables -L -t nat |grep -q 8080; if [ "test$?" = "test0" ]; then echo "Varnish On"; else echo "Varnish Off"; fi'

 

You can now call, varnishon, varnishoff, and varnishstatus next login. So logout and login.

Restart Apache and start up varnish:

service httpd restart
service varnish start

You should be able to access your site on port 80 AND port 8080. The difference? Run a curl command to see the headers:

curl -I http://mysite.com
curl -I http://mysite.com:8080

You’ll see the port 8080 mentions varnish.

Last thing to do is enable the iptables rule: Type in your alias command you put in bashrc:

varnishon

Now port 80 is routing to port 8080, and you have varnished pages, and haven’t touched your cPanel setup!

Considerations: the header shows the page in this weird cPanel workaround setup as 301 moved permanently. Also, the site i was using captured IP addresses, but due to the proxy nature of this setup, the ips captured belonged to the server! The actual way should be to have Apache on 8080 and varnish on 80, and no ip rules at all. If you have access to WHM or cPanel, you are looking for tweak settings, and change the default apache port to 8080 in there! Good luck!

I was replacing an old website hosted on a dedicated CPanel Apache server, with a new kick ass site written in Zend Framework. The problem with CPanel is that they don’t like you farting around with the DocumentRoot of Apache (by default /home/user/public_html/), which for a ZF app would be /home/user/public_html/public.

The way around this, without editing your vhosts or your httpd.conf (people with no dedicated server won’t be allowed to edit these anyway), is to upload a level down and symlink your public folder.

I use Dreamweaver (but ONLY for it’s FTP client!! DW totally sucks!) for my uploads, so in your FTP client I changed the upload folder to / instead of /public_html. Upload your files, and then SSH into the server.

we need to symlink the public_html folder, so make sure you’re not root for this part. ¬†From your home folder:

# rm -fr ./public_html
# su nonrootuser
$ ln -s public public_html
$ exit
# chown -R nonrootuser:nonrootuser /home/nonrootuser/public_html
# chmod -R 0755 /home/nonrootuser/public_html

I’m not sure why, but symlinking whilst I was root seemed to cause problems, hence why i changed user before issuing the command. The chown and chmod fix a 500 error that says
“SoftException in Application.cpp:431: Mismatch between target GID (503) and GID (99) of file “/home/nonrootuser/public_html/index.php”

There we have it! Your ZF app is now loading propertly!