Not sure how long it’s been but I just noticed the other day that my widget was no longer showing my external IP. Instead it’s just stuck “Updating…” Looks like the good people at iSlayer have phased out the script that was used so those of us hanging on to iStat Pro are left out again.

But once again, just like the last fix, this one’s a quick and easy edit too!

The file you’ll need to edit this time is ~/Library/Widgets/iStat\ Pro.wdgt/scripts/core.js

Find this function:
function getExtIP(){

And replace this line:
ipURL = 'http://whatsmyip.islayer.com/?random='+new Date().getTime();

With this line:
ipURL = 'http://www.whatsmyip.us/showipsimple.php?random='+new Date().getTime();

Then, just above this “if” statement:
if(extIP.length < 20 && ipConnection.status == 200 && extIP.match(/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/)){

Add these 2 lines:
extIP_len = extIP.length;
extIP = extIP.substring(16, (extIP_len - 3));

So that you have:
extIP = ipConnection.responseText;
extIP_len = extIP.length;
extIP = extIP.substring(16, (extIP_len - 3));
if(extIP.length < 20 && ipConnection.status == 200 && extIP.match(/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/)){

Now just save the file and restart the iStat widget by either re-adding it, or just click on the widget and hit Command-R.

This was something that I had noticed but didn’t really look into since I was able to operate with it on but today I decided to fix it since I finally needed one of the accounts that don’t use SSL.

The problem is that when you go to your outgoing mail settings, “Use Secure Socket Layers (SSL),” is always checked. When you try to remove it, it just comes back right away or when you leave the page and return to it. Hopefully something Apple will address in their next update (whenever that is).

Luckily, it’s a simple fix. All you have to do is, instead of using the “Default Ports,” select “Use custom port” and enter the port your mail server uses (usually port 25 or 587). Now you’ll be able to uncheck “Use SSL,” and you’ll be able to send out email again!

Thanks goes to Tonden who posted this solution on the Apple forums!

Lovers of the iStat Pro widget will notice that the processes section no longer works. Unfortunately, Bjango stated on their Twitter that there it was unlikely that there would be any further updates to the widget.

However, fortunately for us, a member on the Mac Rumors forum has found a quick and easy fix and all it takes is adding a space in two locations to the widget!

1. Locate your widget, it will be under /Library/Widgets or ~/Library/Widgets
2. Right click it and select: “Show Package Contents”
3. Open Wide.js or Tall.js file in some editor (Wide is for horizontal view, Tall for vertical)

4. Locate the line
WideSkinController.prototype.updateProcesses = function(){
var _self = this;
var exclude = "";
if(p.v("processes_excludewidgets") == 'on')
exclude = " grep -v DashboardClient | ";

if(p.v("processes_sort_mode") == 'cpu')
widget.system('ps -arcwwwxo "pid %cpu command" | egrep "PID|$1" | grep -v grep | ' + exclude + ' head -7 | tail -6 | awk \'{print " "$1""$2""$3,$4,$5""}\'', function(data){ _self.updateProcessesOut(data);});
else
widget.system('ps -amcwwwxo "pid rss command" | egrep "PID|$1" | grep -v grep | ' + exclude + ' head -7 | tail -6 | awk \'{print " "$1""$2""$3,$4,$5""}\'', function(data){ _self.updateProcessesOut(data);});
}
Change “PID|$1″ to “PID| $1″ (Add space before $ sign)

5. Save the changes

Works like a charm!!

Something I’ve wanted for a while is to install a second hard drive in my MacBook Pro but the main thing that held me back was the fact that I actually used my optical drive and removing it wasn’t really an option. But lately, I haven’t really been using it anymore and I figured now was a good a time as any!

I had done a bunch of reading on the subject before going ahead with this from which SSD I should get to what was the best way to configure OSX after the install. Everything looked pretty painless and straight forward and there didn’t appear to be any surprises (famous last words). A friend of mine knew about what I wanted to do so when he came across a $100 rebate from Intel on their 240GB 520 Series SSD, I took it as a sign and ordered the drive right away (Intel, I have yet to see my $100 rebate by the way).

With the SSD down, I looked at drive adapters to replace the optical drive. Going against most people’s suggestions, I went for the OWC Data Doubler Bracket. I was actually going to get a generic one off Amazon or eBay but reviews of people having them not fitting right steered me away. There were alternatives, but I liked the idea of a lightweight bracket and figured it wasn’t worth the hassle dealing with the UK or full on enclosure/adapters. I’ll admit though, it is a little more than I wanted to spend on a small piece of metal.

Now having the hardware down, and Mountain Lion being only a few short weeks away, I decided to hold out on doing the install until it was released so that I could take the opportunity to do a fresh new install of OS X. Today was that day. “Burning” the OS X installer to USB was really easy except that at the end of it, Disk Utility threw an error about Invalid Parameters or something. Doing a quick search actually showed the error could be ignored and the installer was in fact successfully copied to the USB drive.

All set! Time to install the hardware!

Installation of the SSD was as advertised, unscrew these, unplug that, swap form here to there… Extremely straight forward and the supplied tools from Mac Sales meant I didn’t even have to go dig up my own to do the job!

Once installed, I left the old drive unplugged just so there would be no chance of accidentally installing Mountain Lion to the wrong drive. Just as a backup in case there was any need for me to go back to the old drive before I was ready.

OS X install was quick as always. After the initial copy, the installation process only took about 15 minutes if not less and initial boot seemed almost instantaneous. Subsequent boots took a few seconds.

After reconnecting my original drive, I followed the instructions of creating symlinks to my documents, downloads, photos, and music directories. Most things fell into place, like iTunes, which acted like nothing ever happened but some things like ChronoSync, which I use for my backups, had to be set up again since it wasn’t able to follow the symlinks and freaked out about not finding the source directories. Not how I was hoping it would be but something I will have to live with.

Apart from that, I now have my system on the SSD and all my files and documents on the old HDD. Once I’m sure I’ve transferred all my application settings and whatnot, I’ll begin the process of deleting the old system files and moving the data directories to the root of the drive instead of the original user directory where it sits now.

Worth the price of admission? Not sure yet, but I’ll update with another post after I’ve had a chance to really run this setup through. Things do feel quicker but I’ll confirm that after I get over my initial excitement.

Mountain Lion? Can’t say I see too much difference yet, though I have to say I never knew how much I customized my OS until I did this fresh install. There were so many settings I forgot I had changed. Drag lock, double click the title bar to minimize, enabling tab on dialog box buttons, enabling mouse-over highlight in stacks… Not to mention all my little tweaks to Terminal!

Recently a few WordPress sites on my server were attacked by the Blackhole exploit going around. Each time it was removed, it would come back shortly after and after much frustration in trying to find a working solution to the problem, I finally figured it out this morning.

A number of people recommended WordPress plugins like Firewall 2 and Exploit Scanner to stop attacks, but none of these worked (Which is not to say it doesn’t do what it’s supposed to, just wasn’t working for this particular exploit).

I flipped through the access logs in an attempt to find something that stood out, like an exceptionally long URL query string or multiple consecutive accesses to a particular page but didn’t notice anything until I thought about filtering down to just the POST requests to the site. That’s when I found the following entry.

83.69.224.227 - - [06/Mar/2012:10:35:40 -0800] "POST /wp-content/plugins/ToolsPack/ToolsPack.php HTTP/1.0" 200 1 "-" "Mozilla/4.76 [en] (Win98; U)"

The ToolsPack wasn’t anything we had heard of or even recognized and there were only 3 different IPs that accessed this page directly numerous times throughout the day across the affected sites. We had our culprit.

Viewing the source of the file confirmed my suspicions and revealed that all it did was decode and evaluate whatever text was posted to that script.

The only thing I haven’t quite figured out yet is how the script got there in the first place. I found a ToolsPack zip file in the WordPress uploads directory which would suggest something in WordPress allowed it to be uploaded and decompressed to the plugins directory, but what, I’m unsure of.

If anyone has any thoughts or information I’d love for you to comment and let me know your findings!

For now, I’ve removed the files, blocked the IPs and made all the index files 444 (globally read-only) which should help prevent this from happening again.

So I finally went ahead and upgraded to OSX Lion today and overall the process was pretty painless. The App Store makes the purchase and upgrade process super easy, and in under 20minutes, I had the installer loaded and ready to go. It should be noted that, for those who wish to keep a hard copy of the installer should make that copy BEFORE proceeding with the install as once the upgrade is done, Lion will go and clean up after itself, removing the installer.

Since I wanted to keep a copy, I followed these simple instructions on Lifehacker and burned a copy of Lion to DVD for safe keeping. There is also a 650MB recovery partition with Lion on it as well (I’m actually not sure if this was there from the start or if Lion created it) so you can always boot up with that in a pinch.
Read the rest of this entry »

I had this weird problem come up today with cPanel where it wasn’t storing user permissions on databases I was creating.

After digging into the cPanel error log located at /usr/local/cpanel/logs/error_log, I found that I was getting access denied errors to the mysql root user.

DBD::mysql::db do failed: Access denied for user 'root'@'localhost' to database '____' at /usr/local/cpanel/Cpanel/Mysql.pm line 1139

So anything I was trying to do database related wasn’t actually happening (apart from database and user creation, oddly).

After some feeble attempts at recreating the users, databases, and trying to grant all on *.* to root, I came across these simple steps to fix the permissions. You’ll need root and shell access.

Step 1: Add skip-grant-tables to /etc/my.cnf to disable authentication.
Step 2: Restart the MySQL service, and log back in to the mysql command line interface
Step 3: Issue the following commands:

UPDATE mysql.user SET Grant_priv='Y', Super_priv='Y' WHERE User='root';

GRANT ALL ON *.* TO 'root'@'localhost';

Step 4: Remove skip-grant-tables from /etc/my.cnf and restart the MySQL service

Done!!

So I don’t know if this is something that I missed entirely in the documentation, but a while back, one of the drives in my NAS gave up on life and decided to stop working. Being the lazy person I am, and relying on the uber redundancy of RAID6, I left it for a few weeks (including the time after I purchased a replacement drive). In my defence, I lost the key to the drive trays and had to wait until a friend of mine could find me one. (To skip my long winded path to the end solution, just jump to the last paragraph)

In any case, today I swapped in the replacement and in an anti-climactic fashion, nothing happened. In fact, it didn’t even pick up the new drive. I feared that the NAS itself was dead and I would have to go through the painful process of getting a replacement and everything. None the less, I decided to would take a chance and reboot the unit. Luckily, this did the trick and while it still didn’t automatically rebuild the array, it now detected the new drive.

Checking the RAID configuration page, the only available option was to assign the new drive as a spare.

After some digging on the Thecus Forums, the only mention I found was indirectly through another person’s troubleshooting post where he mentions that setting the drive as a spare fixed his issue.

I was hoping to get some solid information that would support this, but I figured I had nothing to lose and at the very least, I’d have a RAID5 array with a hot spare to back me up.

9 hours later, I’m back up and running, and the RAID 6 array is healthy once again. It would have been nice if Thecus had some better documentation available, but I suppose piggybacking on a forum is better than nothing.

In short, if a drive in your RAID array fails, and if after replacing the drive it doesn’t automatically rebuild, just go into the RAID configuration screen and set it as a spare and the NAS will start rebuilding the array at that point.