ExpanDrive

When I’m wailing on a project in bash, I frequently find myself wanting to cd back to the project root. Since we use git, this is the same as the git_root directory. So I wrote a bash function that looped through the directories in the current path and found the one that contained the .git/ directory.

Luckily, I thought to ask on #git if there was an easier way before I posted my script (because no one likes to look like a noob on their own blog). It turns out there’s a one liner. I’ve posted it here, with a little padding so that I can feel like I made a contribution.

function gr {
    ## If the current working directory is inside of 
    ## a git repository, this function will change
    ## it to the git root (ie, the directory that 
    ## contains the .git/ directory), and then print
    ## the new directory.    
    git branch > /dev/null 2>&1 || return 1
    cd "$(git rev-parse --show-cdup)".
    pwd
}

One of the most frustrating things about Apple Remote Desktop is the “authentication failed” errors that pop up from time to time. You’ve got your user name and password right, but for some reason, the client machine just won’t recognize you.

I got the dreaded “authentication failed” error after upgrading one client machine to version 3.2.2, and so I patched together a solution that allows you to solve the problem remotely, using our good friend SSH. It’s all Terminal window commands, but it’s straightforward enough that most users should be comfortable doing it.

Step 1: SSH to the uncooperative client. You can do this via local IP address:

$ ssh [admin username]@[client machine IP address]

Or over Bonjour if a) you don’t know the IP, or b) your router assigns IPs dynamically.

$ ssh [admin username]@[client machine name].local

If you’ve never connected with SSH before, you’ll have to type “yes” before you enter your admin user password when the “Password” prompt comes up.

My machines are all named after deadly sins, so when I do this, it looks like the screenshot below. “Lust” is the computer I’m using, “Wrath” is the remote machine that’s giving me the “authentication failed” error when I try to connect to it using Remote Desktop.

Notice how the computer name listed before “cosmo” has now changed from “Lust” to “Wrath”. Be sure that when you enter any Terminal commands described on this page other than ssh, you’re entering them on the remote machine, not the machine you’re running ARD from. If you don’t pay attention, you could end up deleting a bunch of files that are working just fine.

Step 2: Kill ARD on the remote machine. Once you’re connected to the client, type the command top. This opens activity monitor, listing all the processes currently running on the remote machine. Note the process ID numbers of “ARDAgent” and “AppleVNCServer”, along with ‘ARDHelper” if it shows up.

Once you’ve identified those numbers, open a new Terminal window, SSH to the remote machine again, and then force quit these process by typing kill followed by their process ID number (“PID”).

$ kill 234
$ kill 233

Terminal might whine about quitting ARDHelper because it’s being run by root, but use the sudo command or the bang-bang trick to force the process into submission.

$ sudo kill 228

Step 3: Delete the offending files. As far as I can tell, the whole reason the “authentication failed” error comes up is bad data or bad file paths in the Remote Desktop plist files. It might be possible to fix them with a text editor, but I prefer a less fussy solution: delete them.

Double-check to make sure you’re SSHed into your remote machine, and enter the following Terminal commands, one at a time:

$ rm -rf /var/db/RemoteManagement<br>
$ rm /Library/Preferences/com.apple.RemoteDesktop.plist<br>
$ rm ~/Library/Preferences/com.apple.RemoteDesktop.plist<br>
$ rm -r /Library/Application\ Support/Apple/Remote\ Desktop/<br>
$ rm -r ~/Library/Application\ Support/Remote\ Desktop/

Step 4: Fire ARDAgent back up. Now that you’ve quit the processes and deleted the old stuff, change directories to the ARDAgent folder, then turn everything back on and recreate the plist files. You can do this by entering the following two commands:

$ cd /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/
$ sudo ./kickstart -activate -configure -access -on -users username -privs -all -restart -agent -menu

Step 5: Reconnect to the client machine using Remote Desktop. Re-open Remote Desktop on your computer and go to the Scanner. It won’t remember the name of the old machine, but it will still detect it and list its IP address. Double-click that machine, enter your admin name and password, and your dominion over it should now be restored, all without getting out of your chair.

One of the more routine annoyances of a long day in the terminal is banging out some long command that happens to operate on a file your current user doesn’t have access to.

www@webserver:~$ rm -fr /usr/lib/python2.5/site-packages/buildbot/buildbot.png<br/><br/> rm: cannot remove `/usr/lib/python2.5/site-packages/buildbot/buildbot.png': Permission denied

You declined to sudo the command because you you forgot, were feeling cautious, or were unaware of the permissions bits of the file(s) in question. Now you have to type it again, or switch gears and start up some cursor navigation to prepend your sudo.

Next time, as an easy to use alternative, try:

sudo !!

In bash, !! expands to the last run command. sudo !! sudo’s the last command. That was easy.

Not a tip that is strictly bash related, but useful nonetheless. For those struggling to fix error messages on their Ubuntu whining about of an inability to set locale .

Error message:
perl: warning: Setting locale failed.<br/> perl: warning: Please check that your locale settings:<br/> ...<br/> perl: warning: Falling back to the standard locale ("C").<br/>

Fix: sudo locale-gen en_US.UTF-8

with en_US replaced with your locale.

Ever need execute a command in the context of another user while running as root? Like running sudo from an unpriviledged account – except the other way around.

I had always thought ‘su‘ stood for “super user”, but as it turns out it actually is an acronym for “substitute user” – and it can do exactly what we want.

To execute a command in the context of another user, while running as superuser, you can run su -c, followed by the command, followed by ' - user'.

For example, if I wanted to make a script to pull in the contents of a git repository that is stored in the context of user ‘www’ I could run

su -c \"git --git-dir='/projects/www/.git' pull\" - www

For some more info on su check here