Skip to content

ServerAdmins.NET

Stuff for Server Admins…

Archive

Tag: cpanel

Hey there!

I figure it’s been a little bit, so I’ve gone ahead and decided to update the XCache installer for version 1.3.0, and my favorite control panel, cPanel. :)

This is incredibly easy to do and should get a basic/barebones XCache installation up and going fairly quickly on your CentOS + cPanel machine.

First, let’s grab our XCache sources…

cd /usr/src/
wget http://xcache.lighttpd.net/pub/Releases/1.3.0/xcache-1.3.0.tar.gz

Now, go ahead and unarchive the source, and change into the XCache build dir…
tar -xzvf xcache-1.3.0.tar.gz
cd xcache-1.3.0

Let’s prep our sources for the current PHP ecosystem…

root@SERVER [/usr/src/xcache-1.3.0]# phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519

Now that should have gotten everything sorted with our sources so the XCache install is ready for our PHP version and environment, Let’s go ahead and kick off the build! Keep in mind, this build should be fairly fast and lightweight.


./configure && make && make install

The above line basically says “Run configure, if that is successful w/o errors, run a make, and if that finishes w/o error, run the install”. Once this is complete, you should see a line that says something like the following…

Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20060613/

This is going to be where our xcache.so file is located, however when cPanel builds your php.ini file, it’s going to have that set already. So getting the base module loaded is as simple as running the following command.

echo "extension=xcache.so" >> /usr/local/lib/php.ini

After that, you should be able to do a quick check of the PHP CLI and verify that it loaded properly with the ‘php -v’ command…

root@SERVER [/usr/src/xcache-1.3.0]# php -v
PHP 5.2.13 (cli) (built: Jun 16 2010 09:27:33)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with XCache v1.3.0, Copyright (c) 2005-2009, by mOo

And there you go, you can safely restart Apache now and you should be serving cached content. Please keep in mind, you’ll need to configure your XCache setup to ensure everything is working properly, all we’ve done here is install the base module.

I’d suggest taking a look at our other article regarding the tuning of XCache for a bit more information on this. :)

That does it for now!

A little post here, more for reference than anything… Here’s a list of the common ports used by cPanel for your firewall building pleasure…

TCP
21 FTP
22 SSH
25 SMTP
26 SMTP (Alternative port, configurable via WHM)
80 HTTP
110 POP3
143 IMAP
443 HTTPS
465 SMTPS
993 IMAP4
995 POP3
2082 cPanel (NON Encrypted)
2083 cPanel (HTTPS)
2086 WHM (NON Encrypted)
2087 WHM (Encrypted)
2095 Webmail (NON Encrypted)
2096 Webmail (Encrypted)
3306 MySQL (Only if allowing Remote Connections)

–UDP
53 DNS

It should be noted that if you’re firewalling off your server, you should open up a portrange for the FTP PassivePort Rolloff. Typically these are higher up ports and a wide range, such as 30000-50000. You’ll also need to modify your FTPd configuration to use this portrange as well. If you don’t, you’ll see issues with FTP connections dropping, successful logins, but a hang, pause or delay when dong an ls or beginning a transfer that results in a dropped connection. Typically this will affect ftp clients that are behind a firewall/router doing NAT translations.

Anyway, that’s it, quick and simple. :) Enjoy

I’ve run my share of Hosting operations as a Sr. Admin before and one thing that always *killed* me… Server failures and restorations.

Every shop I’ve been in has primarily been a cPanel shop. It’s what the market demanded, so it’s what we sold. Not only was it simply “what the masses wanted”, it offered an entire suite of scripts, apps and A+ quality support and upgrades that almost brought a tear to my eye. :)

However, the one thing it did not provide, was a quick n’ dirty backup and restore system, let me explain.

cPanels backup system is based around the single user ideology. When you backup a server, it does this on a per cpuser account basis. Now this has it’s pros and it’s cons. It’s nice in the fact that restoring/migrating/tinkering with a single account is easy and *very* fast when you need to do it. The downfall is that when you have to restore 1500+ accounts all at one shot, it’s *slow*. For every single account, it copies over the user data, rebuilds certain configs, clears out the package, brings the domain up and then moves onto the next account.

Now, from an customer support standpoint, this is somewhat nice when restoring a server as you can say “we’re restoring accounts that begin with A now, your account will go live as soon as it’s restored.” The bad side of this is that as soon as those domains start to go live, your server starts to go under load. As you restore more accounts, your configuration files get longer (taking longer to modify/update), Apache starts serving requests, mail is being processed, additional load is placed on the server.

This, gets very slow, very quickly.

Now back in the day, we had a set of servers that housed upwards of 8000+ accounts per machine. They were super lighweight, averaging 25-50M of data and *no* webtraffic, however with a standard pkgacct/restorepkg procedure, at 30-45 seconds per account, we were looking at somewhere in the neighborhood of 2-3 days to fully restore a server. From a customer support standpoint, this *SUCKS* You’ve got thousands of users down for multiple days while pkgacct sits there and does it’s thing… Not pretty, in fact, just plain unacceptable.

Necessity being the mother of invention, myself and another admin set out to find the “better way” of doing this. These accounts were only using around 10 or so G of disk space in total on the machine, it was fast hardware, there *HAD* to be a better way to do this and keep everything in cPanel happy. One highly tuned NFS mount later (jumbo frames on a private network are your friend here, trust me. :P ), and we had our methods in place.

If you open up /scripts/cpbackup on any cPanel machine (checked on 11.25 for this instance) and go to line 240, you’ll see two arrays. @FILES and @DIRS. These are the core files that cPanel needs to do it’s thing.


my @FILES = qw(
/etc/exim.conf
/etc/exim.conf.local
/etc/exim.conf.localopts
/etc/namedb/named.conf
/etc/rc.conf
/etc/named.conf
/etc/proftpd.conf
/etc/localdomains
/etc/httpd/conf/httpd.conf
/usr/local/apache/conf/httpd.conf
/etc/group
/etc/shadow
/etc/master.passwd
/etc/passwd
/etc/fstab
/root/.my.cnf
/etc/ips
/etc/ips.remotemail
/etc/ips.remotedns
/etc/reservedips
/etc/reservedipreasons
/etc/quota.conf
/etc/wwwacct.conf
/etc/remotedomains
/etc/rndc.conf
/etc/secondarymx
/etc/my.cnf
/usr/local/cpanel/3rdparty/interchange/interchange.cfg
);

my @DIRS = qw(
/etc/namedb
/var/lib/rpm
/var/lib/named/chroot/var/named/master
/etc/valiases
/etc/proftpd
/var/named
/etc/vfilters
/var/cpanel
/var/spool/cron
/var/cron/tabs
/var/spool/fcron
/usr/local/frontpage
/var/log/bandwidth
/etc/vdomainaliases
/usr/share/ssl
/etc/ssl
/var/ssl
/usr/local/cpanel/3rdparty/mailman
);

You’ll also need to get /home/ (or wherever your user accounts are stored) and your MySQL DBs as well.

So, rsync these files and directories to your backup server, do a ‘mysqldump -A’ for the global databases (careful with remove mysql servers, this can get ugly) and rsync on over /home/ to your NFS mount and voila! You’ve got EVERYTHING necessary to do a super fast backup (line speed and disk speed being your limitations here) of your cPanel server. Now subsequent backups using rsync will only update files that change, not the entire home directory, so they should be fairly lightweight and fast as well. You can also get jiggy with –link-dest options in Rsync to create multiple nightly snapshots in a differential format as well.

Now, if the proverbial poo hits the cooling device, you perform a fresh install of your OS of choice, grab your cPanel installer and run it, and then just reverse rsync from your backup mount (make sure to use –delete!). After that, one /scripts/upcp –force and your server is fully live!

In the case I mentioned above, this cut a server restoration down from days, to about an hour. It allowed us to make 150+ cPanel servers perform nightly backups (a huge selling point to this day) and all with the tools built into a standard CentOS + cPanel setup.

If there’s any desire for a script to handle this, just go ahead and post in the comments below and I’ll whip something up nice and fast for you. It’s fairly trivial and you can have this rolling in your operation in no time at all.

One item of note, you lose the ability to do single account restores from backup with this method. It *is* an all or nothing, disaster recovery shot. You can always copy over individual files and directories, but you lose the elegance of the cPanel native granular backups.