Subversion client connecting using SVN+SSH

If you have different username from the SVN remote:

Setup ssh_config
Host <www.domain.com>
User <username in the domain.com>

Subversion and SSH

Subversion allows you to use SSH as the network protocol by using the svn+ssh:// scheme in the repository URL. One downside to this is that the only way to specify your remote username is in the URL, for example:

svn+ssh://dribin@svn.example.com/repo

This is all fine and dandy if you’re just doing a checkout, but this can cause problems if you want to use the svn:externals property. If you include a username in your URL, no other user can use the external without your remote password. Ideally, you want to allow each user to use their own username in the URL. Unfortunately Subversion has no way to override the SSH username in the URL. The trick around this is to not use usernames in URLs at all:

svn+ssh://svn.example.com/repo

You can then specify your remote username in your $HOME/.ssh/config:

Host svn.example.com

User dribin

OpenSSH Public Key Authentication

Public Key Setup | Configure ssh-agent Process | Agent Forwarding

Secure Shell (SSH) public key authentication can be used by a client to access servers, if properly configured. These notes describe how to configure OpenSSH for public key authentication, how to enable a ssh-agent to allow for passphrase-free logins, and tips on debugging problems with SSH connections. Password free logins benefit remote access and automation, for example if administering many servers or accessing version control software over SSH.
Public key authenticate can prevent brute force SSH attacks, but only if all password-based authentication methods are disabled. Other options to protect against brute force SSH attacks include pam_tally, or port knocking. Public key authentication does not work well with Kerberos or OpenAFS, which require a password or principal from the client.
Definition of terms used in this documentation:

  • Client: the system one types directly on, such as a laptop or desktop system.
  • Server: anything connected to from the client. This includes other servers accessed through the first server connected to.

Never allow root-to-root trust between systems. If required by poorly engineered legacy scripts, limit the from access of the public keys, and if possible only allow specific public keys to run specific commands. Instead, setup named accounts for users or roles, and grant as little root access as possible via sudo.

For more information, see also SSH, The Secure Shell: The Definitive Guide. SSHKeyChain offers integration between the Apple Keychain and OpenSSH.

Public Key Setup

Key Generation | Key Distribution | Key Access Limits
First, confirm that OpenSSH is the SSH software installed on the client system. Key generation may vary under different implementations of SSH. The ssh -V command should print a line beginning with OpenSSH, followed by other details.
$ ssh -V
OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

Key Generation

A RSA key pair must be generated on the client system. The public portion of this key pair will reside on the servers being connected to, while the private portion needs to remain on a secure local area of the client system, by default in ~/.ssh/id_rsa. The key generation can be done with the ssh-keygen(1) utility.
client$ mkdir ~/.ssh
client$
chmod 700 ~/.ssh
client$
ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
Enter passphrase (empty for no passphrase): …
Enter same passphrase again: …

Do not use your account password, nor an empty passphrase. The password should be at least 16 characters long, and not a simple sentence. One choice would be several lines to a song or poem, interspersed with punctuation and other non-letter characters. The ssh-agent setup notes below will reduce the number of times this passphrase will need to be used, so using a long passphrase is encouraged.
The file permissions should be locked down to prevent other users from being able to read the key pair data. OpenSSH may also refuse to support public key authentication if the file permissions are too open. These fixes should be done on all systems involved.
$ chmod go-w ~/
$
chmod 700 ~/.ssh
$
chmod go-rwx ~/.ssh/*

Key Distribution

The public portion of the RSA key pair must be copied to any servers that will be accessed by the client. The public key information to be copied should be located in the ~/.ssh/id_rsa.pub file on the client. Assuming that all of the servers use OpenSSH instead of a different SSH implementation, the public key data must be appended into the ~/.ssh/authorized_keys file on the servers.
# first, upload public key from client to server
client$
scp ~/.ssh/id_rsa.pub server.example.org:

# next, setup the public key on server
server$ mkdir ~/.ssh
server$
chmod 700 ~/.ssh
server$
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$
chmod 600 ~/.ssh/authorized_keys
server$
rm ~/id_rsa.pub
Be sure to append new public key data to the authorized_keys file, as multiple public keys may be in use. Each public key entry must be on a different line.
Many different things can prevent public key authentication from working, so be sure to confirm that public key connections to the server work properly. If the following test fails, consult the debugging notes.
client$ ssh -o PreferredAuthentications=publickey server.example.org
Enter passphrase for key ‘/…/.ssh/id_rsa’: …

server$

Key distribution can be automated with module:authkey and CFEngine. This script maps public keys stored in a filesystem repository to specific accounts on various classes of systems, allowing a user key to be replicated to all systems the user has access to.
If exporting the public key to a different group or company, consider removing or changing the optional public key comment field to avoid exposing the default username and hostname.

Key Access Limits

As an optional step to limit usage of the public key for access to any servers, a from statement can be used before public key entries in the ~/.ssh/authorized_keys file on the servers to limit where the client system is permitted to access the server from. Without a from limit, any client system with the appropriate private key data will be able to connect to the server from anywhere. If the keypair should only work when the client system is connecting from a host under example.org, set from=”*.example.org before the public key data.
server$ cat ~/.ssh/authorized_keys
from=”*.example.org” ssh-rsa AAAAB3NzaC1…

If a text editor is used to add the from option, ensure the data is saved as a single line; some editors may wrap the public key and thus corrupt the data. Each public key in the ~/.ssh/authorized_keys file must not span multiple lines.
Multiple hosts or addresses can be specified as comma separated values. For more information on the syntax of the from option, see the sshd(8) documentation.
from=”*.example.org,10.*,external.example.com” …

Configure ssh-agent Process

To reduce the frequency with which the key passphrase must be typed in, setup a ssh-agent(1) daemon to hold the private portion of the RSA key pair for the duration of a session. There are several ways to run and manage ssh-agent, for example from a X11 login script or with a utility like Keychain. These notes rely on the setup of ssh-agent via an @reboot crontab(5) entry, along with appropriate shell configuration.

The ssh-agent must only be run on the client system. The private key of the RSA key pair must remain on the client system. Agent forwarding should be used to make the key available to subsequent logins to other servers from the first server connected to.

1. Startup cron job

    The following crontab(5) entry should run the agent at system startup time. The crond daemon on BSD and Linux systems should support the special @reboot syntax required for this to work.

    @reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

    To setup the agent for the first time without having to reboot the system, run the following.

    $ nohup ssh-agent -s > ~/.ssh-agent

    Once the ssh-agent is running, any shells already running will need to source in the environment settings from the ~/.ssh-agent file. The SSH_AUTH_SOCK andSSH_AGENT_PID environment variables set in this file are required for the OpenSSH commands such as ssh and ssh-add to communicate with the ssh-agent on the client system.

    $ . ~/.ssh-agent

    Notes on configuring all shells to be able to run arbitrary commands are available. This reduces the initial setup to the following commands, which can be done from the script reagent.

    $ nohup ssh-agent -s | grep -v echo > ~/.ssh-agent

    $ allsh – < ~/.ssh-agent

    If csh or tcsh is being used instead of a Bourne-based shell, replace the -s argument with -c, and the source command used instead of . in any running shells.

    2. Shell startup script changes

      The shell’s startup script on the client system will need to be modified to pull in the required environment settings from ~/.ssh-agent and setup useful aliases. The agent settings in ~/.ssh-agent should not be read in if the client system is being connected to as a server. Remote connections set the SSH_CLIENT environment variable, so~/.ssh-agent must not be read in when this variable contains data.

      [ -z “$SSH_CLIENT” ] && . $HOME/.ssh-agent

      alias keyon=”ssh-add -t 10800″

      alias keyoff=’ssh-add -D’

      alias keylist=’ssh-add -l’

      The -t option to ssh-add will remove keys from memory after the specified number of seconds. This option prevents the keys from being left unlocked for long periods of time. Older versions of OpenSSH will not have the timeout -t option.

      For the csh and tcsh shells, slightly different configuration of the agent and aliases is required. Consult the relevant ssh-agent(1) and shell documentation.

      Once the ssh-agent is running and shell configured to read in the appropriate settings and set easy aliases, enable the key then test a login to a remote server. Thekeyon will only need to be run when initially adding the private key data to ssh-agent, and only rerun if ssh-agent is restarted or the key is removed with keyoff.

      client$ keyon

      client$ ssh server.example.org
      server$ exit
      client$ keyoff
      Use the keylist command to see what keys are in the agent process.

      $ keylist

      1024 01:a1:aa:34:21:bc:7d:a4:ea:56:a4:a1:1a:c5:fa:9f /home/…/.ssh/id_rsa (RSA)
      If password free logins do not work, see tips on debugging problems with SSH connections to work out where the problem may be.

      To make other applications not run from a shell aware of the agent, the environment definitions in the ~/.ssh-agent file will need to be read into the software in question. Consult the documentation for the software to see whether this is possible.

      Agent Forwarding

      For simple client to server connections, SSH agent forwarding will not be a concern. However, if from the server connected to, one logs into other servers, SSH agent forwarding will need to be enabled. If SSH agent forwarding is disabled, a private key must be available on the proxy system that is recognized by the server being connected to.
      To enable forwarding, either use the -A option to ssh when connecting, or set ForwardAgent in an OpenSSH config file, such as ~/.ssh/config. Note that command line arguments override the user-specific configuration file, which in turn can override the global ssh_config configuration file, if any.
      Host *

      ForwardAgent yes


      ForwardX11 no

      Agent (and X11) forwarding may represent a security risk, providing more options to an attacker on a compromised server to work back to the client system. If paranoid, disable Agent and X11 forwarding by default, and only enable the features where needed. Also enable StrictHostKeyChecking and use configuration management software such as CFEngine to distribute a global ssh_known_hosts file to all client systems.

      Fix USB problem for Mac OSX iDeneb 10.5.5

      Heres how to fix the USB problem for my Mac OSX Leopard iDeneb 10.5.5 packaging:

      UPDATE (09/28/08): I just figured that after updating to 10.5.5, I started getting USB drives not mounting problem again. I am still using 9.2.0 kernel and system.kext. It appears that since 10.5.5, the IOUSBMassStorageClass.kext is now not included as a plugin in the IOUSBFamily.kext, but separately in Extensions folder. Somehow with 9.2.0 kernel and system.kext, the kernel never picks up the updated massstorageclass kext. So I went ahead and copied this kext to the plugin folder of IOUSBFamily.kext and corrected the permissions. The USB drives mount fine now with updated USB kexts but older kernel and system.kext. I have not investigated extensively, so there may be some other cause. But if anybody cares, then it solved this for me.

      UPDATE: 06/01/08 05/13/08: At the end of this update, you will find my original post dealing with a workaround procedure (Lingon Method) for solving USB, Firewire problems, etc. They may still work for you if nothing else works. But majority of people should get it solved with the method below and keep in mind all the points mentioned here. Credit goes to Mysticus C* for making a USB fix installer for an easy solution. So here we go!

      ( A ) CHECK YOUR BIOS FIRST:

      You may have one or all of these options:
      enable: plug and play
      enable: usb legacy support (this is only needed if you want your usb hdd dvd/cd roms flash disks to be recognized at boot for various reasons, like booting off from usb dvdrom, or hdd or flash memory etc. If disabled, this does not affect at all while in the OS, since the OS (OSX or Windows) will load its appropriate drivers.)
      enable: usb keyboard and mouse (this will enable you to work with usb keyboard and mouse at boot. Otherwise, they may not work until any OS is loaded)

      ( B ) MAIN CAUSES OF USB NOT MOUNTING ISSUE:

      (Some abbreviations: S: System L:Library E:Extensions C:Caches)

      1) Incompatibility problem: The problem is caused from having different (non-matching) versions of kernel (mach_kernel) and system.kext. Say you have 9.2.0 kernel, but system.kext version is 9.2.2 This will cause USB not mounting issue…

      How to check kernel version:
      The easiest way to check kernel is running terminal window (applications/utilities/terminal) and type:
      CODE
      uname -a

      It will show a long line and at the end of the line it should say the version. Check the figure below.

      How to check system.kext version:
      Open a finder window, go to /S/L/E and find the file named “system.kext” right click on it, and click on Get Info. In the Get Info window, you will see the Version number. Alternatively, you can right click on the kext, click “show package contents”, and open the “info.plist” file (in text editor, for example). It should show a line like this:
      CODE
      <key>CFBundleVersion</key>
      <string>9.2.2</string>

      Here is how it should look like:
      Attached File  kernel_and_systemkext_version.jpg ( 235.1K ) Number of downloads: 3684

      Both should match in versions. If you have 9.2.2 kernel, then system.kext should also be 9.2.2. However, if your kernel and system.kext versions are not matching, that is then the root of the problem. So in order to fix these issues, use the installer provided below. Once you can confirm the details and you know you have non-matching versions, you can continue to Install Guide and follow the instructions

      2) PCGENUSB2 problem: There is another possible way that things may not work as intended. This is however a very specific situation and may be needed for some of you. You must know your system details. There is a good chance there is someone out there who has a similar configuration. Therefore, searching and reading first really helps. The problem is called: “USB 2.0 aka high speed bus is not working”. This problem exists on certain laptops (and old desktop configurations) that contains non-standard bioses, or some old motherboards. In order to fix this issue, “PCGENUSB2.kext” can be installed as part of plugins inside “IOUSBFamily.kext”. Kalyway installation adds this by default. To check it, go to /S/L/E and right click IOUSBFamily.kext, open package contents, go to plugins folder and see if you have this kext there). What it does is that it forces the bios to release the information regarding the USB 2.0 controller, so that OSX can handle high speed bus as well. Nevertheless, most people have recent hardware configurations and may not even have this issue and much less need it. On the other hand, it seems for at least some of them, having PCGENUSB2 actually complicates or worsens their USB problems (for example, see noam’s post here having a weird wireless USB issue). So it may be advisable to remove this unnecessary part and leave IOUSBFamily.kext vanilla.

      How you may got this pcgenusb2 file?:

      * You deliberately installed it yourself.
      * You installed Kalyway 10.5.2 dvd with default settings (by default, PCGENUSB2 is selected in the patches section).

      What to do about it?:

      This you may have to verify yourself if you need it or not. If you are sure that you have the USB 2.0 issue, that you must install the pcgenusb2 file, then do not delete this. So uncheck the last option in the installer (If the option is checked, the installer places a vanilla IOUSBFamily.kext that lacks this PCGENUSB2). A cautionary warning: although PCGENUSB2 helps for those folks who need it, it may cause some USB devices to not work as intended. Sorry, there is no other way… (or buy a new mobo smile.gif )

      If you are sure that you dont have this issue and don’t need it, make sure you check the last option so that it installs a vanilla IOUSBFamily.kext.

      ( C ) HOW-TO GUIDE FOR FIXING THE ISSUE “USING USB fix 1.3.MPKG” (aka USB Fix Installer)

      1 ) Download the zip file
      2 ) Extract the file on your desktop or where ever you like
      3 ) Open the folder wherever you extracted the file
      4 ) Double click/run the file “USB Fix 1.3.mpkg”
      5 ) This has to be installed on the partition you are running OSX, so, no location change on this version
      6 ) Click on “Customize”, to be able make your own choices…
      7 ) By Default: “9.2.0 System.kext only” and “USB Family Original Restore Backup” is selected.

      Reasons for default selections:

      * I see that many people are using Kalyway 10.5.2 DVD, which by default has 9.2.0 sleep kernel, selected but installs 9.2.2 system.kext… To solve one of the two issues, you need to have correct system.kext. So this is why I made 9.2.0 system.kext only default
      * As default on the Kalyway 10.5.2 DVD, PCGENUSB2 is also selected. This is a full driver package that is needed only on handful of mobos/laptops which has problematic bios that doesnt release the USB 2.0 high speed bus information to OS as a result it causes High Speed ports to not work. However majority of the people do not have this issue… Therefore I made this by default selection for people who accidently installed pcgenusb2…

      Although at this stage you can restart, I HIGHLY RECOMMEND Steps 8,9,10 that are optional but useful on some unique situations…

      8 ) Open a finder window, and locate /S/L/Extensions.mkext file. Right Click on it, and select Move To Trash (enter password of course later)
      9 ) Locate /S/L/E/C/com.apple.kext.info file and same right click and move to trash
      10 ) Restart and at boot press F8 where it waits for 5 secs. Type: -v -f (this is gonna recreate driver caches and fast boot caches. the reason why we are doing 7,8 is sometimes these caches prevent new drivers from loading. Although Leopard has auto update function on these caches, sometimes better take precaution…)

      WARNING: The installer is fairly safe but still use it at your own risk. Any problem, please report smile.gif

      Attached File  usb2rd1.png ( 122.57K ) Number of downloads: 2738

      DOWNLOAD (usb_fix_1.3.mpkg.zip)
      Update: 05/18/08: New Installer version 1.3; Installer fixed for force-deleting of kexts; Have been tested extensively. If you had used earlier version and were unsuccessful in getting your problem solved, I urge you to try this one out. There was little bug in the earlier version.

      The below given information is ONLY FOR THOSE FOLKS who like to tinker on their own inside the hood just to make sure that the fix is performed 100%. If you are using going to use the installer, you don’t need to read this. Here is what you can do to manually replace the relevant system.kext . The replacement below is for 9.2.0 system.kext . You can find other versions elsewhere or use pacifist to extract from the installer above.
      1) Remove the current non-matching system.kext
      2) Remove the Lingon created plist, eg USBstarter (it is in /Library/LaunchDaemons folder), if you have created one using the previous method I had described before (see the end of this post below)
      3) Put the 9.2.0 system.kext in /System/Library/Extension folder
      4) Repair permissions:
      CODE
      sudo chown -R 0:0 /S/L/E/System.kext
      sudo chmod -R 755 /S/L/E/System.kext

      5) OPTIONAL: If you don’t need PCGENUSB2, then delete IOUSBFamily.kext and replace a vanilla copy in its place. Repair permissions for this one as well.
      5) Delete the extension.mkext file and the file inside /S/L/E/Caches folder (com.apple.kext.info)
      6) Restart. Use -v -f option during boot during rebuild the cache (Press F8 at the darwin bootloader to get to the boot option, if needed). Plug in any USB drive. It should work wonders. Don’t worry if you don’t see IOUSBMassStorage.kext in Terminal using kextstat after boot. It gets invoked once you put a USB device and the kext will also be visible in Terminal

      Attached File  System_9.2.0.kext.zip ( 151.92K ) Number of downloads: 2354

      ( D ) GENERAL INFORMATION
      I am adding this section for tid-bits that we gather from discussions in this thread.

      [1] This solution should fix your Firewire issues (that are related to this non-matching problem) as well. Firewire devices should mount now.

      [2] If you happen to replace the IOUSBFamily.kext but figured that you actually need PCGENUSB2, here is a place to get IOUSBFamily.kext that has the PCGENUSB2.kext in its plugins.
      http://osx86.wikidot.com/utilities-resources

      [3] If you are a blackberry user and you get something about the current being insufficient for charging check drivers etc, check Toonces Katt’s post #212 for a fix.

      [4] If you have matching kernel and system.kext but still find that USB devices do not mount or would only mount sometimes, the problem may be caused by other hardware such as problematic card readers. Once again, check Toonces Katt’s post #223 how removing the card reader (a cheap Dell one) helped him diagnose and solve the USB problem.

      Happy USB plugging!

      LioNEXT

      ————————————————————————————————————–
      *******************************************************************************
      ————————————————————————————————————–

      Below is my original post for posterity and for learning purposes. You can also use this if you can not solve the problem using the above method. I would also suggest reading this so that you get acquainted with troubleshooting mac problems.

      [UPDATES]
      The updates below were using Lingon method.

      Update 04/30/08: McKack and BoNeS solved problem of Firewire devices not mounting with this method as well. See post #54 and post #231 by adding daemons for:

      kextload -b com.apple.iokit.IOFireWireAVC
      kextload -b com.apple.iokit.IOFireWireSBP2

      Update 04/09/08:
      Following USB related kexts should be loaded for the devices to work ( check with kextstat | grep “USB” ). Also, see post #17 below.

      com.apple.iokit.IOUSBFamily
      com.apple.driver.AppleUSBUHCI
      com.apple.driver.AppleUSBEHCI
      com.apple.iokit.IOUSBUserClient
      com.apple.driver.AppleUSBHub
      com.apple.driver.AppleUSBComposite
      com.apple.iokit.IOUSBHIDDriver
      com.apple.iokit.IOUSBMassStorageClass

      See the attachment below for a screenshot of Lingon app and the things that need to be checked.
      Attached File  Lingon.pdf ( 742.57K ) Number of downloads: 1142

      Update 04/08/08: Make sure you check the box next to Enable and then hit save. If there are more than one kext that does not get loaded, create daemon for each kext and enable and save.

      [/UPDATES]

      Alright, here is my USB problem and how I resolved it and I believe it probably can resolve some other issues as well.

      My USB devices like pen drives or USB external storage disks won’t mount in Leopard 10.5.2. Well, let me qualify my statement. On my configuration, they would do so with stock kernel but then I won’t have shut down and restart. So I installed Netkas’ sleep/shutdown kernel (modified toh 9.2.0), which works absolutely well for me, but now USB devices do not mount. I read somewhere that at every startup, kexts get their links from the kernel. So one has to appropriately match kernel with kexts. So the system.kext and kernel should be compatible. Since Netkas’ kernel is 9.2.0 (and not 9.2.2), some stuff doesn’t work (I hope he will release updated kernel).

      So I confirmed that IOUSBMassStorageClass kext does not get loaded during startup. In Terminal,
      CODE
      sudo -s

      enter password (don’t worry if you don’t see it biggrin.gif )
      CODE
      kextstat | grep “USB”

      There is no com.apple.iokit.IOUSBMassStorageClass loaded.

      (There is also a small app called USBProber available from apple in its USB debug kit that you can also use to see directly to check what kexts are loaded for USB and globally).

      Now if you type in Terminal:

      CODE
      kextload -b com.apple.iokit.IOUSBMassStorageClass

      So now the appropriate kext would load and everything would work.
      (credits to TheG33K:
      http://forum.insanelymac.com/index.php?s=&…st&p=532849 )

      So after looking for a way to create an applescript or shell commands that would run at startup, I found little overwhelming for this rookie. I could not manage to run the command in the above link with script. Then I came across this little app, Lingon, from Peter Borg

      http://lingon.sourceforge.net/

      Install this
      click new script/user daemon
      Box 1: Name it as something (eg. USBstarter)
      Box 2: put the required command or app; in this case:
      CODE
      kextload -b com.apple.iokit.IOUSBMassStorageClass

      Box 3: select the second option “run it when it is loaded by the system at startup or login”

      Check the box next to “Enable” (right top corner)

      Hit Save. It will recommend restart. Restart and enjoy USB mounting all the time with Shutdown/restart/sleep (with S3) all well. smile.gif

      [I have seen that if I clean out kernel and other caches etc using a system utility like Cocktail , the plist (or in other words, kext won’t load). It needs double reboot to get it loaded again. But after that, it will get loaded everytime. If for some reason, it still does not work, open lingon again, uncheck “Enable” and check it back again and hit save. Now it should load. I am not sure why this is so, since the USBstarter.plist is always present in the /Library/LaunchDaemons folder]

      It should solve many other USB problems also. Please do post your USB problems and solutions you have come across.

      Mac OSX Installed Apps

      My Mac OS X (iDeneb 10.5.5) Installed Apps:

      Programming Tools:
      • Eclipse Ganymede
        • eclipse-cs
        • crap4j
        • subversive
      • IntelliJ IDEA 8
        • Checkstyle-IDEA
        • JFormDesigner

      Servers:
      • MySQL 5
      Applications:
      • Transmission Bittorrent
      • Skype
      • Adium
      • Firefox
      • Microsoft Remote Desktop
      • Adobe Reader 9
      • Adobe Flash Plugin
      • Adobe Shockwave Plugin
      • Pacifist
      • MacFuse and NTFS Driver
      • Traktor Pro
      • Traktor Studio 3
      • Ableton Live 6
      • Microsoft Office 2008 (OpenOffice 3)
      • EZ 7z
      • Rar Expander
      • Perian Video Codecs
      • VLC
      • Senuti (trial license)
      • OSX86Tools
      • Parallels Desktop 4
        • Windows XP running on Coherence
      Applications that does not have crack:
      • Oxygen 10 XML Editor
      Tweaks:

      change the login background:
      [robg adds: It’s the simple things that can make using one’s OS of choice more pleasant :). I used Terminal to create a backup of the original image first, just in case. After cding to the CoreServices directory, I then did sudo mv DefaultDesktop.jpg DefaultDesktop_old.jpg, then moved my new image in.]

      change the desktop background
      /Library/Desktop Pictures/Nature/Aurora.jpg

      change the “about this mac” picture
      /System/Library/CoreServices/loginwindow.app/Contents/Resources/MacOSX.tiff

      take screenshot:
      command + control + shift + 3

      take screenshot of variable size:
      command + shift + 4

      take screenshot of specific application window:
      command + shift + 4 , then spacebar

      What is lacking support:

      – shutdown not shutting down properly. sometimes you need to wait longer
      – USB not working correctly. you need to restart in order to detect the USB device.
      *workaround* in another file.
      *cause* kernel is not same version as System.kext
      – wifi for intel 3945bg no driver *under development*
      – can update to 10.5.6?

      Subversion switching to a new location

      When switching to a new Subversion (SVN) location or migrating your project, use the command line:
      svn --username [your username] switch --relocate [old location] [new location]

      If you are using SVN externals and needs to update it:

      1. Checkout project using:
      svn --non-interactive --ignore-externals co [location of project]
      2. Update the externals definition:
      svn --non-interactive propset svn:externals "[directory that contain external] [external location]" [project name]
      3. Commit changes
      svn commit -m "updated svn externals for branch XXX-XX"

      Hope this helps!