If you’re trying to package a cPanel account on the command line and you’re hitting and error that looks something like this:
Category: hosting
So, you boot up your shiny new AWS CentOS 6 server, and run the cPanel installation script. Next you reboot the server… ever… and it never comes back online? My question to you: is your IP also licenced for CloudLinux?
IPAddress is already an active IP
Sometimes, when something odd happens to your server (most of the time intentionally, though not in an ideal situation) when you go to add an IP address to your server, you’ll see this error:
$IPADDRESS is already an active IP. Skipping $IPADDRESS .. already added !
And then when you check the cPanel logs (because you’re a good admin like that), you’ll see this error:
[2013-10-26 15:21:41 -0500] info [xml-api] $IPADDRESS is already an active IP. [addips] version [1].
Well, when that happens there are a plethera of things to check and correct. Hopefully one of these will fix it for you.
Switching from pureftp to proftp through WHM says it completed, but you’re still running pureftpd? Try to do it on the commandline and see this error?
If you’re trying to install cPanel, and it hangs on:
\_ /usr/local/cpanel/bin/apache_conf_distiller
and your post-cpanel install easyapache bails on:
!! Failed to install CPAN Perl module(s) Digest::SHA1 Crypt::PasswdMD5 !!
I quit my job yesterday.
The company I’ve been at for 6.5 years.
The job I’ve done for four of those years.
I am leaving the department I helped build. The company I put blood, sweat, and tears in to.
The most common question I’ve gotten: What made you quit?
It’s making people unsettled how simple the answer: Nothing. It’s just time to move on.
Today there was a little bit of kick-in-the-gut, and panic, as the “omg wat will we do without youuuuuuuu”‘s started to roll in. And I felt sick for a little bit. That kind of sick that makes you think about going back to that terrible relationship, because you can’t possible exists without the lover you’ve just left.
But this breakup wasn’t caused by a single, angry, moment. It’s just time for us to go our separate ways. And amicable break up means I won’t be gone until May 14th, but I’m no less full of anticipation.
And I cannot TELL you how excited I am to see the open road in front of me. Even if it’ll mean a little broken heart.
I’m in love with this. “It’s about a few people loving you up close, and about those people being enough.”
I want to help the music industry. I want to help the artisan industry. I want to help the art industry.
I want to help all of my friends (known and unknown) who want to distribute their art. I have ideas, lots of ideas. And I have resources. But I’m going to start here: If you are an artist of any kind, and you need hosting for your art and for a website, and for distribution, I’m your lady. Let’s make this happen.
WordPress is one of my absolutely favorite pieces of software. It’s so simple, relatively intuitive, and knows exactly what its goal is. It’s elegant, one might say. For all of its splendor, however, it can be a serious resource hog. The fact that it is database driven means, given the right conditions, a WordPress site could cause significant load on the server that hosts your blog. You don’t understand what that means, you say? Well, allow me to explain it to you.
Every time you load a website, hosted anywhere on the planet, you are loading a series of files. Sometimes those files can reference other files, or (as in the case of a WordPress blog) databases. A database, as defined by wikipedia, is “an integrated collection of logically-related records or files consolidated into a common pool that provides data for one or more uses.”
While I could write an entire entry about the merits of good database organization (and I may later) suffice it to say: when you load the front page of bennycrampton.com, you hit the database for this blog (at a quick count in the source code) no less than 15 times, and load at least 5 different files. If my site were popular, with a modest 30 hits-per-minute (hey, a girl can dream!), my server would be serving 150 files, and getting content from the database 450 times, every minute.
That’s a lot.
The reason that’s a lot is not memory use, and not CPU use (though those might both come in to play depending on the plugins used on the site), the reason you will start to see problems with that is a thing called Disk I/O Wait.
Without getting too technical: Disk I/O (or Input/Output) is the writing to, and reading from, a hard-drive. No matter how awesome or fast your harddrive is, it can still only do one thing at a time: specifically reading or writing to a single file. This is where the ‘wait’ part gets involved. The more disk I/O is occuring, the longer a programs wait times become. How long, depends on a lot of things, but the things I’ve seen effect it most:
1) Extremely active databases.
2) Poorly designed slightly active databases.
3) {a large group of other things}
4) Failing drives.
So… with all of this potential fail, how do you keep your server stable, your site up, and your wallet *not* empty?
Enter Caching!
Caching (from wikipedia): “In computer science, a cache (pronounced /?kæ?/ kash) is a component that improves performance by transparently storing data such that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere.”
That’s right! All of the sudden that 150 file and 450 database reads go down to 1: the page that was generated previously and stored in cache. I cannot adequately express how much of a difference caching makes. I have seen servers serving a single site that got Dugg go from repreatedly crashing to serving 7Megs of traffic, just by enabling caching.
While WordPress doesn’t have any built-in caching, a number of 3rd party developers have created caching plugins for WordPress which offer various levels of simplicity and control.
http://wordpress.org/extend/plugins/wp-super-cache/
WordPress SuperCache is the plugin that this site uses. You can control how often the cache refreshes and who gets to see cached pages through the wp-admin interface.
From the site:
This plugin generates static html files from your dynamic WordPress blog. After a html file is generated your webserver will serve that file instead of processing the comparatively heavier and more expensive WordPress PHP scripts.
The static html files will be served to the vast majority of your users, but because a user’s details are displayed in the comment form after they leave a comment those requests are handled by PHP. Static files are served to:
1. Users who are not logged in.
2. Users who have not left a comment on your blog.
3. Or users who have not viewed a password protected post.
http://wordpress.org/extend/plugins/w3-total-cache/
W3-Total-Cache is for a more advanced user, and gives you more fine-tuned control, and can give you even better performance. It can also be coupled with memcached to drastically reduce your page load times.
The fastest and most complete WordPress performance optimization plugin. Trusted by many popular blogs like: mashable.com, briansolis.com, pearsonified.com, ilovetypography.com, noupe.com, webdesignerdepot.com, freelanceswitch.com, tutsplus.com, yoast.com, css-tricks.com, css3.info and others — W3 Total Cache improves the user experience of your blog by improving your server performance, caching every aspect of your site, reducing the download time of your theme and providing transparent content delivery network (CDN) integration.
There are more than these two out there, but the beauty of the majority of them: they are generally all easy to install, and will make both you and your webhost happy. When your site gets dugg, or get slashdoted, or gets posted to twitter by Neil Gaiman, and threatens a #NeilWebFail, your caching plugin will save your site, your stress level, and your uptime.