If you’re trying to package a cPanel account on the command line and you’re hitting and error that looks something like this:
Categories
Pkgacct error
Category: tech
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?
Categories
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 spent hours and hours trying to figure out what was wrong with my newly rsync’ed music library tonight.
First, the list of problems: I had a large number of greyed out folders that were owned by the user/group of ‘_unknown’ (in ls), couldn’t be modified, and had odd extended file attributes. They looked like this in the finder (I forgot to get a screenshot of terminal, so you’ll just have to trust me):
Categories
Adding to AutoCorrect
Apple has done some very cool things with each iteration of iOS, and while I’m excited for iOS7, I still like the little ins and outs of iOS6. This trick was actually one I learned from the ultimate Apple hacker in my life, but I figured I’d post it for anyone that doesn’t have a fanboy in their pocket.
So, we all say things that autocorrrect doesn’t like. This is the easiest way to get around it I’ve found. Have some pictograph directions.
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.