Usually I want to open Gmail in Chrome and URLs pointing to my development server in Firefox. For everything else I use Safari.
There is this nifty free app called LinCastor that enables you to register your own handler for an URL. Although it had beed designed to register your own non-standard URL schemes, it can intercept standard http and https as well.
In LinCastor (which you need to double-click twice to fully open for editing):
Add a new URL scheme
Choose AppleScript handler
Paste the following code in, (replacing the stub code at the bottom):
if (|URL| of args starts with "https://mail.google.") then
tell application "Google Chrome"
open location |URL| of args
else if (|URL| of args starts with "http://") then
tell application "Firefox"
open location |URL| of args
tell application "Safari"
open location |URL| of args
Obviously you should customize the code to suite your own specific needs. You can validate the script right in LinCastor before saving/activating it.
I use the same mechanism to launch 'site specific browsers apps' created by Fluid. For example I have a JIRA app wrapper which looks for anything staring with http://issues.
[crarko adds: I tested this, and it works as described. LinCastor requires OS X 10.8 or later. I tried it in 10.10 beta 2, and it also worked there. There's not much documentation for it, so tinker around a bit to get the result you want.]
One of the primary objectives was to document a setup where the VPN-connected iOS device routes all the device's traffic through our network – i.e.:
All the iOS device's traffic goes through our network and is encrypted while doing so -- so the cellular data and WiFi parts of the device's traffic can't be monitored.
All unencrypted (and normall SSL browsing, etc.) traffic emanates only from our LAN through our network's (land-based/hard-wired) router.
This gives our mobile devices the benefit of some site filters provided by our firewall appliance (another 'how to' I have planned).
A major objective of the on demand aspect of the VPN capability is to have the a VPN connection automatically created whenever the iOS device is either only on a cellular network or on a WiFi network that's not ours (i.e., so the above requirement is automatically fulfilled).
Both the IPSec and OpenVPN configurations include setups using only user+password/account-based authentication as well as certificate-based authentication.
Although the iOS device instructions are specific to an iPhone, they also work for other iOS devices -- the user just has to find the equivalent items for the VPN settings.
Although the server side of the instructions is specific to the pfSense open source router, the setup configuration will apply to many other routers – the user will simply have to find the equivalent settings for that router/VPN appliance.
For anyone interested in a good router, read my Comments About pfSense for a strong but conditional recommendation.
[crarko adds: An ambitious project, and hopefully it should work with iOS 8 as well.]
Mousecape is a new open source Mac App which is available on GitHub to finally allow you to create and use your own mouse cursors, or 'capes' as the app calls them.
Once you download the app, there is a remastered version of the Svanslös cursor set created by Max Rudberg which is retina-screen ready.
Mousecape is as non-instrusive as possible, never asking you for your password for anything. It works by using private APIs created by Apple to register system cursors so it has no performance hit at all.
Capes, or cursor sets, are applied for as long as display state doesn't change, meaning until you change resolution, monitors, sleep your computer, reboot or logout. However, inside of the application is a helper application that will detect when the cape is reset and will apply it again.
Mousecape is available for free, open source and with no obligations. Users can create and share their own capes that are animated and bring new flair to the operating system.
Many people continue to use iWork 09 apps, because they contain features missing in the newer versions. However, having the older apps on your system mean a constant nagging from Apple to update to the newer versions. If you do download the newer versions, then it is impossible to make the older apps the default for your documents. The old Get Info » Change All trick doesn't work.
Here's what to do to remedy that.
First, make a backup. Then install the latest iWork apps. Your older versions get moved to a subfolder called iWork 09. That's why you have the backup.
Next, move the NEW apps to an external disk or other partition. You can then restore the 09 apps to the /Applications folder. Or leave them in the subfolder if you prefer.
Having the apps on different volume from the system disk lowers their priority, so the 09 apps in your /Applications folder remain the defaults for your documents. What is more, any further updates will update the newer versions on your external drive, leaving your 09 apps untouched.
[crarko adds: I rather wish I had done something like this before updating. Maybe rolling back tp the 09 suite from Time Machine and then following this procedure will work.]
This is my take/an update on las_vegas' hint I found here awhile back for running OS updates without creating a user on a Mac. It is applicable to any system 10.5 and up.
This can be helpful if you have a Time Machine backup that's on a newer OS than your install media, or if you're selling/donating your Mac as it saves the new user having to update things.
First things first, wipe your drive (and zero it if you don't trust the end user of this computer) and reinstall your desired OS.
Once your OS is installed, boot to your install media or the Recovery Partition if available. Open Terminal from the Utilities option in the menubar. In the new Terminal window, type the following:
This will bring up the Password Reset utility. Click Macintosh HD or whatever your HDD is called. You'll notice the only user account that's available is root. Enter a password you'd like to use/remember, though it doesn't really matter as we'll be disabling root and removing this password later. Click save, close the password reset utility and go back to working in Terminal. Now you'll want to enter the following command:
This will create the file on Macintosh HD that tells the computer it has completed the setup so you're able to skip the process and login with the root account we just enabled.
Close Terminal and reboot the computer into the Macintosh HD. You should be greeted by the login screen with an option that says Other. Click Other, enter root as the username and the password you chose to login.
Proceed with Software Updates and any optional software you'd like to install, making sure to install for All Users if prompted. Also keep in mind that any preference changes you make will only apply to the root user, so there's no sense in wasting any time customizing the look, feel and general operation of the computer.
After all software is installed, open up Terminal once more. Enter the following code:
This will remove the file we originally created and re-enable the setup assistant to help create the new/first user on the Mac.
Next, open up Directory Utility. This can be found in Users & Groups in System Preferences. Click Login Options, then click Join... by Network Account Server. You should then see the option Open Directory Utility.
Once in Directory Utility, click Edit in the menubar and then select Disable root user. As a note, this can be done while logged in as root. Close Directory Utility and restart the computer, booting back into to your install media or Recovery Partition. Open up Terminal one last time and enter:
Once the Password Reset utility has appeared, click the root user once more. Instead of changing the password, however, simply click the Reset button to reset Home Folder ACLs.
Reboot your Mac, confirm you see the Setup Assistant and you're ready to move onto restoring your backup or selling your computer!
I've become somewhat obsessed with the faces feature in iPhoto. Currently, I have about 7000 unidentified faces in my library. I knock out a few hundred here and there. It's oddly satisfying, but I go to a lot of large events - events where a lot of people look familiar because they are regulars, but I don't know them. This makes finding faces rather cumbersome, especially since the method of ignoring faces requires the mouse. Everything else can be done with the keyboard. Plus, doesn't track repeatedly ignored faces, so the same faces keep showing up. Well, I've discovered a way to work around these cumbersome limitations.
Doing everything with the keyboard makes things go a lot faster. If you're using the Find Faces feature and skip faces you don't know (because you don't want to pause to use the mouse), the next time you click on Find Faces, you'll be presented with those same unknown faces over and over again. They build up and always get presented in the same order, so you end up spending a lot of time skipping them before you get to new faces.
To avoid this, just name all these unknown faces 'Unknown' (or some other word with an uncommon starting letter). Then all you have to do to ignore a face (once you've tabbed to it) is type a 'u.' After you've labeled a bunch, open the 'Unknown' face album and bulk-confirm all the unwanted faces. Now the next time you use Find Faces, you'll get right to the new faces.
A few other time-saving tips:
You can create a smart album containing unnamed faces, open the album and hit the info button, then start tabbing and naming. The photos with unnamed faces will disappear as you update them. This allows you to have a good idea of your progress.
Not naming a face when the person's name is on the tip of your tongue, can make them rather hard to return to when their name pops into your head. I find it useful to name them something like '?Alan's Wife' or some other memorable note. All such names will be at the top of your Faces album listing (because of the question mark), and you can change the name of all occurrences simply by renaming the album.
Let auto-complete do most of the work. Most times, the first few letters are all you have to type before iPhoto fills in the rest of the name. Note, iPhoto uses Facebook, your contacts, and your previously named faces for auto-fill, but it skips contacts' middle names and does not include nicknames.
When confirming faces, if you come across a different face that you know, you can right/control-click and name it. Plus, sometimes all it takes to remember a name is the context of the photo, but the Find Faces feature does not let you zoom-out to see the whole image. Yet, when confirming faces, you can unzoom/zoom with the switch at the top-right of the window. I find that the confirm-faces interface is a faster way to find new faces than the Find Faces feature and I was methodically going through each face album to find new faces this way before I discovered the smart album trick mentioned above.
[crarko adds: Faces is not a feature I use very much, but this might get me to start. By the way, sorry about the slow July. I've been on vacation a bit, and the hint queue is pretty bare at the moment. I'll be putting up a couple of polls related to Yosemite as we await the public beta. Things will probably remain slow until that release.]
I should have stumbled on this one years ago but I have just realised typing in Safari's address bar and unconsciously doing Ctrl+a to go to the start of my query, that it works.
We recall these life saving Unix text editing shortcuts:
'Ctrl+a' : go to start of the line
'Ctrl+e' : go to the eol
'Ctrl+k' : delete all chars to the right of the cursor
I have tested those with success in various standard Dialog Boxes, TextEdit windows andin Safari's address bar; it seems to be a relatively system wide standard. Of course no luck with MS apps, they use their non-standard Alt+arrows (when most other Mac apps use the widely known Ctrl+arrows).
First my sincerest apologies to all those who knew and if there ever was a similar hint since 2003 in the DB. [crarko adds: At the time this hint was originally submitted the site's search function was not working.]
Ever watchful of posting etiquette, I did Google to make sure I was on to something greater than being ridiculed. Alas, after some efforts, I did find a full reference elsewhere. Still I post this stale and quasi 'hint', feigning to take comfort I may help some (one or two ?) and trying to find pitiful schadenfreude at the same time.
[crarko adds: Cute. There are plenty of older versions of this notion, this being a handy one. Now that the site's search feature is back up I'm sure there are others. Nevertheless, there are enough Mac users around who are new since 2001 that a little refresher isn't all bad.]
If you are having trouble with Logmein Hamachi starting up correctly, the following script will check to see if the connection is up. If it is, it will attempt to restart and then send you an email when it's done.
You'll need to update these variables with your own data:
Also update the machine names and IP address (e.g. test_ip_address) in the case statement.
You can use the command hamachi list (from a Terminal window) to get your network ID and IP addresses.
Once you set this up, you can run this from any of your connected machines and it will try to connect to the other machine. If it cannot, it attempts to get Hamachi working again.
Here's the script:
# Script to restart the Hamachi connection if it is not working
# user command "hamachi list" to find the hamachi network you are connecting to
case $machine_name in
*) echo "You are using an unknown machine, named [$machine_name]. Exiting"
echo "Checking Logmein Hamachi network connectivity..."
echo "You are using [$machine_name]. Checking IP Address [$test_ip_address] on [$test_machine]"
IS=`/sbin/ping -c 5 $public_ip_address 2> /dev/null | grep -c "64 bytes"`
if (test "$IS" -eq "0") then
echo "Your internet connection does not appear to be working. Aborting check"
IS=`/sbin/ping -c 5 $test_ip_address 2> /dev/null | grep -c "64 bytes"`
if (test "$IS" -gt "2") then
echo "Your Logmein Hamachi connection appears to be working."
echo "There appears to be a problem with your Logmein Hamachi connection."
echo "I will check again in 10 seconds..."
IS=`/sbin/ping -c 5 $test_ip_address 2> /dev/null | grep -c "64 bytes"`
if (test "$IS" -gt "2") then
echo "Your Logmein Hamachi connection appears to be working now."
echo "There is still a problem with your Logmein Hamachi connection. Attempting to fix by restarting Logmein Hamachi..."
hamachi go-offline $hamachi_network
hamachi go-online $hamachi_network
echo "OK, we should be back up!"
echo "Your Logmein Hamachi connection on $machine_name needed to be cycled on/off.
Could not connect to [$test_ip_address].
It may also mean that $test_machine is down." | mail -s "Hamachi Connection Down on $(date '+%m/%d/%y @ %H:%M:%S')" $email_address -f email@example.com -F "Hamachi Connection Problem on $machine_name"
What I did next was add a new column AirplayPassword= to the placeholder CSV file and put a password in. I then uploaded the placeholder for an AppleTV and it added the Airplay password to my AppleTV Device in ProfileManager.
Just yesterday I added 20 AppleTVs to Profile Manager, I could have saved a few steps with this hint.
[crarko adds: If you don't know about Apple Profile Manager for OS X Server here is a description of it's capabilities. Perhaps they've noticed penetration of AppleTV's into business and college conference rooms. I've been seeing more of them used basically as portable projectors.]
So you finally want to take the plunge and convert from gitolite managed repositories and Jenkins to doing everything with Mavericks' Xcode Server? It turns out it's actually not that hard.
Disclaimer: I just figured this process out, everything appears to work (pulling the repository, committing/pushing back to the repository after making changes. I think that everything should be working properly outside of my very basic tests, but they were very limited.
Converting gitolite repositories for Xcode server.
Find your repositories folder (for me i had a special 'git' user so the repositories folder was in /Users/git/repositories).
Create a tarred gzip file (as admin with following settings) to create carbon copies of the directories preserving ownership and permissions:
sudo tar cpz -P --exclude .DS_Store -f repositories.tgz /Users/git/repositories
Copy this tgz file to the new server (if it is in fact a new server).
Extract the file to your Desktop.
Change the owner to the proper owner expected by Mavericks' Xcode server:
sudo chown -R 94:70 ~/Desktop/respositories/
Change the directories to have the proper permissions:
sudo chmod -R 0777 ~/Desktop/repositories
Each repository has a config file inside it, gitolite gives different default configs than Xcode server, and it's important that they match up with what Apple expects. For my gitolite config files they all looked like this:
So I replaced all the config files contents for every repository with that and everything appears to work seamlessly as if Xcode had created the repositories.
Make sure the server app is NOT running and then move all of your repositories into /Library/Server/Xcode/Respositories/git/
9. Open the Server app, choose the Xcode option in the sidebar and then choose the Repositories tab and all of your repositories SHOULD be visible. This will keep your commit histories intact (I havent tried reverting to them or anything, but I assume it should work)
For the more curious, this is how I determined the gid's for _teamserver and _www:
dscl . -list /Users UniqueID
[crarko adds: I haven't tested this one, but I am planning to set up such a server so it would be great to hear what people think of Xcode server in general, as well as the specifics of this hint.]