Sequel Pro.app for Mac with Vagrant

You can use Sequel Pro with Vagrant by setting up SSH under ‘SSH’ on the connections page.

The MySQL credentials will be the ones used inside of the Guest VM.

For example; Host, Port etc won’t be the same on your host machine, so use the host and port number that MySQL recognizes inside of the VM.

For your SSH, use the Host that you specified in your Vagrantfile, and the SSH user unless changed should be ‘vagrant’. Then for the password (unless changed in your Vagrantfile) you are going to need to click on the key icon in the password field. This will open a dialog to open a file, so then find the private key that vagrant created and select that.

Usually the private key can be found at ~/.vagrant.d/insecure_private_key

KSFetch Annoyance on Mac OS X 10.8 ML with ‘Hands Off’ or ‘Little Snitch’ Firewall.

So you have some firewall on your Mac OS X setup, and it nags about 4 times a day about wether you want to grant KSFetch access to the net. Thats the thing that has been bugging me for months and finally decided to figure out a way to sort out this little menace.

As it turns out, this is a common issue with an ongoing discussion in several places across the web, namely here and on here at google groups.

KSFetch is a process for autoupdating of any and all google products installed on your system. Chrome being one of the most popular. Unfortunately, KSFetch is recreated each time it wants to check for updates and placed in a new directory, part of which is randomised. The randomised part of it means your firewall won’t know of it every time a new one is created even though you may have selected ‘always allow’ or ‘always deny’ because its looking at the wrong directories due to the nature of the random string in each. This results in your firewall having a ridiculous list of KSFetch entries in it and a continual nagging from your firewall about wether to allow or deny.

Another aspect to the issue is that, not only can we not block programs that keep moving and re-spawning in new locations effectively in our firewalls but that it does it every single bloody hour as the default. Its insanity.

We have only but a few options. The first of which is to change the respawn time through a configuration option that is available for setting its spawn interval, the second option is to uninstall every single google product on your system. Great choice huh?

You cannot remove the updater apparantly because if you do, any installed google product you have will reinstall it. So basically your trusted google software is acting like a virus/malware. Awesome.

This is what you need to type into terminal to change the interval:

This one is for 24 hours.
$ defaults write com.google.Keystone.Agent checkInterval 604800

This one is for 7 days
$ defaults write com.google.Keystone.Agent checkInterval 4233600

The interval is measured in seconds, so thats the examples i gave above for some good defaults you could use, which should mitigate the annoyance and frustration of the issue. Ultimately though, google is at fault for implementing such a bizarre and incredibly annoying approach to solving a rather simple problem that stubbornly won’t play well with firewalls, won’t allow itself to be removed without removing all google products and that creates new instances of itself for each updater check.

Mac OS X 10.8.2 ML Kernel Panic

So i had 2 kernel panics within the last 2 days. Diagnosing the issue can be very difficult. But it seems that the issue could have been caused some a few stray kernel extensions left over from some software i uninstalled quite some time ago.

I believe the cause was Blackberry’s desktop manager software, namely because; 1) i uninstalled it about 6 months ago, and 2) because it seems to have left a bunch of daemons after its uninstall that remained, and the logs show that they kept spawning new instances, quiting/crashing and then waiting 10 seconds and spawning again. The reason i came to notice it was more for the fact that it was throttling continually. That got my attention!

Check your /Applications/Utilities/Console.app for more info on whats going on in your system. The information there can be very difficult to make sense of, and most of it is harmless despite lots of things in the log that say things like ‘failed’ and ‘warning’ etc.

I manually used the locate database to find the blackberry remnants and quickly removed the daemons and so fourth. Just do a keyword search for anything like:

  • locate com.rim.
  • locate blackberry

After removing all that crud via the rm utility and a reboot i had another kernel panic the next day, and then i came across a great site for diagnosing kernel panics on mac os x and you might want to check it out

I used the kextstat | grep -v com.apple to show all of the 3rd party kernel extensions and found the following:

macpro:~ admin$ kextstat | grep -v com.apple
Index Refs Address Size Wired Name (Version)
18 0 0xffffff7f80947000 0x18000 0x18000 com.rim.driver.BlackBerryUSBDriverInt (0.0.74) <17 16 15 13 12 5 4 3 1>
52 0 0xffffff7f8138d000 0x10000 0x10000 com.metakine.handsoff.driver (2.0.4) <7 5 4 3 1>
107 0 0xffffff7f807c0000 0x5000 0x5000 net.telestream.driver.TelestreamAudio (1.0.5) <86 5 4 3 1>
108 0 0xffffff7f807ac000 0x4000 0x4000 com.vara.driver.VaraAudio (1.0.3) <86 5 4 3 1>
113 3 0xffffff7f82316000 0x36000 0x36000 org.virtualbox.kext.VBoxDrv (4.1.12) <7 5 4 3 1>
114 0 0xffffff7f8234c000 0x8000 0x8000 org.virtualbox.kext.VBoxUSB (4.1.12) <113 47 12 7 5 4 3 1>
115 0 0xffffff7f82354000 0x5000 0x5000 org.virtualbox.kext.VBoxNetFlt (4.1.12) <113 7 5 4 3 1>
116 0 0xffffff7f82359000 0x3000 0x3000 org.virtualbox.kext.VBoxNetAdp (4.1.12) <113 5 4 1>
117 0 0xffffff7f809bf000 0xc000 0xc000 com.taoeffect.ispy.kext (2.0.2) <5 4 3 1>

The items below shown in bold are the ones i decided were the most likely culprits:

  • com.rim.driver.BlackBerryUSBDriverInt (0.0.74)
  • com.metakine.handsoff.driver (2.0.4)
  • net.telestream.driver.TelestreamAudio (1.0.5)
  • com.vara.driver.VaraAudio (1.0.3)
  • org.virtualbox.kext.VBoxDrv (4.1.12)
  • org.virtualbox.kext.VBoxUSB (4.1.12)
  • org.virtualbox.kext.VBoxNetFlt (4.1.12)
  • org.virtualbox.kext.VBoxNetAdp (4.1.12)
  • com.taoeffect.ispy.kext (2.0.2)

As for the rest, Metakine is a firewall, virtualbox is a VM like parallels, and that left me with the rest, which i presumed were vital to the operation of audio drivers etc.

So, the iSpy is a part of Espionage.app, which i promptly uninstalled, but again this left crapola on my disk, which i had to manually track down and remove.

The blackberry stuff however was a bit more difficult. I did however find a discussion on the blackberry board where a user had extracted the uninstall shell script and shared it. I tried to run this but it complained about the lack of ref being available. So i just stripped out everything but the rm and other lines that removed mention of BB related stuff. After a quick running of the script and a reboot, sure enough kextstat was no longer reporting the issue. Also, boot time improved which i think is due to not having a daemon continually spawning and throttling the system every 10 seconds. Also note, sometimes these days my machine would hang on boot, and i am not experiencing that issue anymore since removing the blackberry daemons and drivers. If your machine hangs on boot, definitely check out your kexts.

The script i mention can be found here, but i show it below for your convenience:

#!/bin/bash -x

CALLERS_UID="$1"
REFCOUNT_PATH="$2"
DCALL_PATH="$3"

if [ $UID -ne 0 ]; then
# Test that the script is run as root.
echo "Script must run as root"
exit 1
fi

if [ ! -x "$REFCOUNT_PATH" ]; then
echo "Ref tool not found"
exit 1
fi

PKREF="pkgutil --pkgs=com.rim.blackberrydesktopmanager.Application.pkg"

if [ -d "/Library/Receipts/blackberrydesktopmanager.pkg" ] || [ ! -z ${PKREF} ]; #MAYBE THIS SHOULD BE /Library/Receipts/blackberrydesktopmanager.pkg INSTEAD?
then
#unregister the Desktop Manager App with BBLaunchAgent
/Library/Application\ Support/Blackberry/BBLaunchAgent.app -ndefault /Applications/BlackBerry\ Desktop\ Manager.app >> /dev/null

/bin/rm -fr "/Applications/BlackBerry Desktop Manager.app"
/bin/rm -fr "/Library/Receipts/blackberrydesktopmanager.pkg"

# Delete the Application Support folder and preferences for ALL users
/bin/rm -fr /Users/*"/Library/Application Support/BlackBerryDesktop/"
/bin/rm -f /Users/*"/Library/Preferences/com.rim.blackberrydesktopmanager.plist"
/bin/rm -fr /Users/*"/Library/Caches/com.rim.blackberrydesktopmanager"

/Library/Application\ Support/BlackBerry/BBLaunchAgent.app -ipndefault /Library/Application\ Support/BlackBerry/IPModemPasswordDialog.app >> /dev/null
/bin/rm -fr "/Library/Application Support/BlackBerry/IPModemPasswordDialog.app"

REFCOUNTVSP="\"$REFCOUNT_PATH\" -unreferenceVSP"
if [ ${REFCOUNTVSP} -eq 0 ]; then
/bin/rm -fr "/Library/Modem Scripts/RIM IP Modem.ccl"
/bin/rm -fr "/Library/Frameworks/RIM_VSP.framework"
/bin/rm -fr "/Library/Receipts/blackberryvsp.pkg"
/bin/rm -f "/Library/Preferences/com.rim.vsp.plist"
fi

REFCOUNTVSPDR="\"$REFCOUNT_PATH\" -unreferenceVSPDR"
if [ ${REFCOUNTVSPDR} -eq 0 ]; then
/bin/rm -fr "/System/Library/Extensions/RIMBBVSP.kext"
/bin/rm -fr "/Library/Receipts/blackberryvspdr.pkg"
/bin/rm -f "/Library/Preferences/com.rim.RIMBBVSP.plist"
fi

REFCOUNTDR="\"$REFCOUNT_PATH\" -unreferenceDR"

if [ ${REFCOUNTDR} -eq 0 ]; then
# unload the driver
if [ ! -x "$DCALL_PATH" ]; then
echo "DCAll tool not found"
else
DCALL_RESULT="\"$DCALL_PATH\""
fi
fi

REFCOUNTFW="\"$REFCOUNT_PATH\" -unreferenceFW"

if [ ${REFCOUNTFW} -eq 0 ]; then
# BBLaunchAgent is run by the users, not root. We walk through all logged in users and
# attempt to quit the BBLaunchAgent just in case multiple users are logged in simultaneously.
for currentUser in users; do
sudo -u "{currentUser}" /bin/launchctl unload /Library/LaunchAgents/com.rim.BBLaunchAgent.plist
done

# NOTE: The previous loop might fail on 10.4 if the user name is >8 characters (the 'users' command
# on 10.4 returns only the first 8 characters of the user name!). So, we explicitly
# unload using the numeric userid just in case.
sudo -u "#${CALLERS_UID}" /bin/launchctl unload /Library/LaunchAgents/com.rim.BBLaunchAgent.plist

# stop the daemon that is run as root
/bin/launchctl unload /Library/LaunchDaemons/com.rim.BBDaemon.plist

/bin/rm -fr "/Library/Frameworks/RimBlackBerryUSB.framework"
/bin/rm -f "/Library/LaunchDaemons/com.rim.BBDaemon.plist"
/bin/rm -f "/Library/LaunchAgents/com.rim.BBLaunchAgent.plist"
/bin/rm -fr "/Library/Application Support/BlackBerry"
/bin/rm -fr "/Library/Receipts/blackberryframeworks.pkg"

/bin/rm -f "/Library/Preferences/com.rim.RimBlackBerryUSB.plist"
/bin/rm -f "/Library/Preferences/com.rim.RimLaunchAgent.plist"

/bin/rm -f /Users/*"/Library/Preferences/com.rim.RimLaunchAgent.plist"
fi

if [ ${REFCOUNTDR} -eq 0 ]; then
# unload the driver
KEXTSTATUS="/sbin/kextunload -b com.rim.driver.BlackBerryUSBDriverInt"

/bin/rm -fr "/System/Library/Extensions/BlackBerryUSBDriverInt.kext"
/bin/rm -fr "/System/Library/Extensions/RIMBBUSB.kext"

/bin/rm -fr "/Library/Receipts/blackberryusbdriverint.pkg"

/bin/rm -f "/Library/Preferences/com.rim.BlackBerryUSBDriverInt.plist"
/bin/rm -f "/Library/Preferences/com.rim.RIMBBUSB.plist"
fi

# SnowLeopard stores receipts differently then Leopard and vice versa.
# This unforunatly does not work on Leopard either so we need to support both receipt removal methods
# To get ride of SnowLeopard receipts:
/usr/sbin/pkgutil --forget "com.rim.blackberrydesktopmanager.BlackBerryFrameworks.pkg"
/usr/sbin/pkgutil --forget "com.rim.blackberrydesktopmanager.BlackBerryUSBDriver.pkg"
/usr/sbin/pkgutil --forget "com.rim.blackberrydesktopmanager.BlackBerryUSBDriverVSP.pkg"
/usr/sbin/pkgutil --forget "com.rim.blackberrydesktopmanager.BlackBerryVSP.pkg"
/usr/sbin/pkgutil --forget "com.rim.blackberrydesktopmanager.Application.pkg"

else
echo "Not Found"
exit 1
fi

echo "Success"
exit 0

You can run it via:

// Lets set the permissions on it, i named my version removeBB.sh
$ chmod +x ~/removeBB.sh
$ sudo sh ~/removeBB.sh

If you have any problems, edit the file AT YOUR OWN RISK and run it to bypass some checks that can miss some stuff.

The iSpy stuff from Tao-effect is for the espionage app for hiding stuff on your mac. I got it as part of the mac bundle, and i never really wanted or even used the thing, so i removed it as-well.

I also found some other kexts i don’t have the logs for anymore to show you, but i also removed them, they were:

  • Sophos anti-virus
  • SyncMate
  • app4mac

If you don’t know what the kext is your looking at, then before removing it, go google it! Find out what it is your considering removing before doing it, it could be important!

From time to time, while your removing such crud and using locate to find stuff, the locate tool will still show the files as being there despite them being deleted and you will want to update your locate database, you can do that like this:

$ sudo /usr/libexec/locate.updatedb

It can take about 2-5 minutes (sometime longer depending on your setup). Once done, files you already deleted won’t show up anymore.

Also, courtesy of the apple discussion boards i found a dicussion regarding kernel panics, unbootable machines and being unable to get past the password screen at login. The generally accepted solution seems to be to remove a symlink that the OS will rebuild upon next update.

$ sudo rm /var/audit/current

You will need to reboot after that.

Good luck.