I’m excited to announce that this year I will be speaking at the  cPanel conference, so if you haven’t yet registered, make sure you do it soon!  The conference will be held in cPanel’s hometown of Houston, TX at the Westin Oaks Hotel between Oct 4-6,2010.

My topic specifically will be covering full server automation from start to finish, essentially showing you how to deploy fully-configured cPanel servers with even touching a bash prompt.  You’ll learn where cPanel stores it configuration files, how to configure services using cPanel’s service templates, and what scripts will save you time by automating simple tasks.

Hope to see everyone there!

If you have a fully automated cPanel/WHM setup method used to deploy a large number of servers, you’ve probably found it to be annoying that upon loading WHM for the first time, you’re greeted with a setup wizard that you have to click through.  To skip this wizard, all you need to do is touch a file:

touch /etc/.whostmgrft

This will tell WHM to skip the setup wizard altogether. However, if you haven’t already, you’ll want to add the following pieces to your automation which are usually configured in the setup wizard:

• IMAP – /scripts/setupmailserver (courier | dovecot  | disabled)
• DNS – /scripts/setupnameserver (bind | nsd | disabled)
• FTP – /scripts/setupftpserver (pure-ftpd | proftpd | disabled)

You should also create the /etc/wwwacct.conf file, with the following contents:

ADDR 123.456.789.123
CONTACTEMAIL your@emailaddress
CONTACTPAGER
DEFMOD x3
ETHDEV eth0
FTPTYPE pureftp
HOMEDIR /home
HOMEMATCH home
HOST server.domain.com
LOGSTYLE combined
MINUID
NS ns1.yourdomain.com
NS2 ns2.yourdomain.com
NS3
NS4
NSTTL 86400
SCRIPTALIAS y
TTL 14400

Derived from : http://www.cpanel.net/blog/integration/2010/05/skipping-the-whm-getting-started-wizard.html

You can allow users to use their own configuration file for AwStats in case they are in need of customizations not provided by the server’s main config.  To enable this option, add the following to /etc/stats.conf:

allow_awstats_include=1

Alternatively, you can go to WHM > Statistics Software Configuration, and click on Allow Awstats configuration Include file

This will allow users to have an awstats.conf.include file in /home/$username/tmp/awstats, which can be used to override settings from the main AwStats configuration for the server.

There was a situation today where I had to mass-move a bunch of accounts from one partition to another.  WHM’s Rearrange an Account function does this one account at a time, but to move over 50 of them, a more scripted solution was necessary.  Here’s how I did it on a live server without causing any downtime:

Scenario: Moving over 50 cPanel accounts from /home4 to /home3 on a live dedicated server

Step 1: Grab the list of users

Done with a simple one-liner:

for user in `cat /etc/passwd | grep /home/ | cut -d: -f1` ; do echo $user >> /root/users ; done

Step 1: Rsync all the data over

This part can be fairly CPU-intensive, so you may want to bandwidth-limit or renice the rsync which will slow the transfer, even if done locally. You need to copy the data on one disk to the other:

for user in `cat users` ; do rsync -av --bwlimit=8000 --delete /home4/$i /home3 ; done

You may want to run this command a few times depending on how much data is being moved over.

Step 3: Update configuration

Paste the following commands into a file (replacing the partition names with the ones pertaining to your server), chmod 755, and run:

for user in `cat user` ;  do

replace /home4/ /home3/ — /var/cpanel/userdata/$user/*
replace /home4/ /home3/ — /etc/proftpd/$user
replace /home4/$user /home3/$user — /etc/passwd
ln -s /home4/$user /home3/$user
replace /home4/$user /home3/$user — /home3/$user/etc/*/passwd

done

Now, run:

/scripts/rebuildhttpconf && service httpd restart

service pure-ftpd restart (or proftp)

When you’re sure that everything is moved over, you can remove all the user data from the old partition.

cPanel currently has four templates that are visible to your users:

Default website: Appears to visitors who navigate to a site that points to the server but isn’t configured in Apache
Account move: Appears to visitors who navigate to a site that has moved
Connection selection: Appears to visitors who navigate to a site that is experiencing a connection or firewall problem
Account suspended: Appears to visitors who navigate to a site that has been suspended

You can modify the templates in WHM > Web Template Editor, but what if you have multiple servers you need to update templates for?

The templates are stored in a simple location:

/var/cpanel/webtemplates/$user/$language/$templatename.tmpl

$user : The reseller user (all accounts under this reseller will use its templates)

$language: The language in use for cPanel

$templatename: The name of the template, with .tmpl appended:

Default website: default.tmpl
Account move: moving.tmpl
Connection selection: redirect.tmpl
Account suspended: suspended.tmpl

This way, if you wanted to (for example) change all the suspended pages for accounts owned by root, simply drop your html code into the following file:

/var/cpanel/webtemplates/root/english/suspended.tmpl

The way cPanel works in regards to these templates, is to redirect all sites matching relevant situations (such as suspended websites) to a compiled CGI file in /usr/local/cpanel/cgi-sys:

movingpage.cgi
defaultwebpage.cgi
suspendedpage.cgi
redirect.cgi

The files load up the template and serve them to the visitor reaching the website or cPanel for the account in question.

We’ve developed our first cPanel 11.25 cheat sheet, now available for your downloading pleasure.  The sheet is comprised of common file, script, and configuration locations for help at a quick glance.

File: cPanel 11.25 Cheat Sheet (31.99KB) Added: 07/02/2010 Downloads: 180 Description: cPanel ports, file/folder locations, scripts, and log locations

More cheat sheets will be available soon! Check back on our Cheat Sheets page for more.

Cpanel 11.25 restructured the way that bandwidth RRD files are being processed, in that each service has two RRD files – one for peak, and one for rate.  The “peak” file is used for long timespans of a month or longer, and the “rate” file covers a timespan of a week or less.  The following is an example of files that would be created for domain.com:

domain
domain.com.5min
domain.com.hour
domain.com
domain.com.5min
domain.com.hour

Re rebuild the RRD databases for a user, run:

/usr/local/cpanel/bin/rebuildbwrrd <user>

To do this for the entire server:

/usr/local/cpanel/bin/rebuildbwrrd –all

Beware though that cPanel 11.25 requires a  bit more disk space for the new bandwidth graphs, so if you have /var on a separate partition and there won’t be enough room, I recommend doing the following:

mv /var/cpanel/bandwidth /home

ln -s /home/bandwidth /var/cpanel/bandwidth

You’re basically moving the bandwidth graphs to another location and linking them to /var/cpanel/bandwidth.

CPanel utilizes a script called “optimizefs” that removes the atime attribute from certain files on the system. For larger servers, this can create a lot of i/o load for a problem that can be fixed simply by mounting your file systems with the noatime flag if your file system is ext2 or higher.

The atime attribute is used by Linux to mark when a file was last accessed, and is understood to be a resource drain when enabled for an entire filesystem.  cPanel attempts to address this by removing atime attributes from a specific list of files.  You may see a command like this in your root crontab:

45 */8 * * * /usr/bin/test -x /usr/local/cpanel/bin/optimizefs && /usr/local/cpanel/bin/optimizefs

This cron basically applies the following command to a number of files and directories:

chattr +A /path/to/file/or/directory

Instead of using cPanel’s band-aid fix, it’s preferred to remove the atime attribute from the filesystem altogether. To do this, add noatime to the file system properties for each usable partition listed in /etc/fstab. For example:

LABEL=/ /  ext3    defaults,usrquota,noatime 0 0
/tmp /var/tmp ext3    defaults,usrquota,bind,noauto,noatime 0 0

Then remount each file system. For the example above using the root partition ( / ):

mount -o remount /

*In some cases, a reboot may be necessary

Now, you can remove the cron job and still get the same benefits of not having your operating system record file access times:

sed ‘/optimizefs/d’ -i /var/spool/cron/root && service crond reload

Additional Resources:

http://www.faqs.org/docs/securing/chap6sec73.html

When hosting websites, whether as a mainstream hosting provider, a hobby, or to supplement another service, it’s your job to make sure your customers have access to technical support in case they need help.  Customer support is one of the highest expenses that a web host can encounter.  Just my making a few small changes, you can reduce the amount of customers that contact you for help, and increase your profit margin.

Revamp your “Welcome” documentation

The welcome documentation is usually an email that is sent to a new client containing server and account access information. It’s important to cover your bases to avoid ending up with confused users that have no other avenue but to ask you for help – something that tends to be frustrating for a new user.  Your welcome email should not be wordy, but rather bulleted and easy to read, and separated into sections.  It should contain any information your users needs to access their account and server, steps to get started, and how to find help.

Use video tutorials

Sites like Demo Demo provide flash tutorials for common control panel software, that can be branded to your company and used in your support center. Making it known to your customers that flash tutorials are available to explain the procedures for common tasks may prevent them from contacting you.

Establish a knowledge base

A knowledge base is generally used by hosting providers to provide information to address common questions and problems encountered by customers.  If you’re seeing a common question being risen by your users, consider making the answer to that question more visible by adding it to a knowledge base full of FAQs, or adding it to your welcome documentation.

Don’t do anything that provokes a response

It should be expected that changes and upgrades will need to take place during the life of a user’s account.  However, unless you’ve planned for the worse, don’t make changes that your customers will notice and likely contact you about unless you’ve notified them first.  If you’re making a change that may affect users, make sure your users know how the change can affect them and what steps to take if they have a problem.  It’s not recommended to play fast and loose with items that will attract user attention in a negative light, so plan your upgrades and changes accordingly.

Be open

Set up a blog or status site that your customers will know to check if they are experiencing a problem.  For example, Dreamhost has a website their customers can access to find out about outages or problems, thus preventing them from contacting the customer support center to find out what’s going on.  Customers tend to appreciate more transparency  when it comes to problems that can affect their site.

Test, test, test

It should go without saying that you should not deploy changes on your hosting servers without thoroughly testing them first.

Keep an eye out

If you are not monitoring your network, you’re a step behind from even the worst of the hosting providers out there.  You should be monitoring anything that could cause an interruption in service, as your customers should not know about downtime before you do.  Knowing when a problem will happen before it does will easily prevent  problems that can result in thousands of dollars in losses and customer support costs.

Be responsive

If you see a problem that is continually affecting multiple clients, do something about it.  Sites getting hacked? Consider implementing a solution to block the attacks and issuing an advisor so your customers know you are looking out for them.  Hosting servers are in constant need of maintenance to make sure they are running quickly and securely.

Get it right the first time

Anyone that manages a support center will know that each response, phone call, chat, and email costs money.  Addressing your customers’ requests and problems correctly and thoroughly the first time will limit your follow ups.

I wrote this nice one-liner for a user in the cPanel forums asking how to change all their current default addresses to :fail: -

http://thecpaneladmin.com/files/changedefaultaddr.sh.txt

Before you do anything like this, you should back up /etc/valiases. Keep in mind also that you can change the default address for new accounts in WHM > Tweak Settings.

Ref: http://forums.cpanel.net/f5/force-default-mail-address-all-accounts-158722.html