If you've ever wanted to copy an Apple Remote Desktop setup from one machine to another, you need to move a number of files. Open Terminal, and run the following commands -- modify the username and machinename settings as necessary for your environment. Note that the lines that start with ### are explanatory; don't type those...
A mobile user account can take forever to login if you are at a different location, but have an internet connection. To login a mobile account, OS X will first try to connect the Open Directory server. If you have a domain search list in your network preferences that lists your company's domain, this can cause long timeouts.
To fix this, remove the company's domain from the DNS search list, and ask your company's administrators if they can specify this as a DHCP parameter.
As we all know by now, with the 7.3.1 firmware update to the AirPort Extreme (802.11n) Base Station, we finally get decent read/write performance from attached disks. The pre-7.3.1 firmware was buggy and slow, but the new firmware rocks, and AirDisks are finally ready for prime time (as well as supporting Time Machine -- yay!).
One of the energy/disk saving features of the new base station firmware is that it will spin down attached drives if they have not been accessed in approximately 10 minutes. This is good for saving a couple of watts of power, as well as prolonging the life of a hard drive. If a drive is used as a Time Machine volume, the delay in waiting for the drive to spin up and be accessible is quite acceptable.
However, if the drive is being used as a network share for data (in my case, iTunes media and archival data), the five to ten second delay caused by spinning up is not acceptable (at least to me). And since there's no parameter to disable disk sleeping on the AirPort, I wrote a trivial program and launchd plist file to "tickle" the disk every few minutes to keep it spinning (and just that one disk - I have two other USB disks attached to that basestation that are for Time Machine, and I do want them to spin down).
When mounting an SMB share from a Windows 2003 server, I ran into the problem that after about five minutes, the share would disconnect and I would not be able to reconnect to it at all. My system log would say things like this:
KernelEventAgent24 tid 00000000 received VQ_NOTRESP event (1)
KernelEventAgent24 tid 00000000 type 'smbfs', mounted on '/Volumes/xxxx', from '//xxxx;xxxx@xxx.xxx.xxx.xxx/xxx$', not responding
KernelEventAgent24 tid 00000000 found 1 filesystem(s) with problem(s)
loginwindow23 1 server now unresponsive
kernel smb_iod_reconnect: The reconnect failed to xxx.xxx.xxx.xxx! error = 4
I found a solution, after trying many other things. It is probably due to a bug in the network software of Apple or the server. I use a laptop which normally uses a wired connection with fixed IP as a first choice, but there is wireless connection in the building, too, and my laptop pulls an IP number from the DHCP server at the same time via AirPort.
The Airport connection is (normally) not doing anything, as all the traffic goes over the wired Ethernet connection. Apparently after five minutes of inactivity, the Windows server goes on standby, and when my Mac tries to reconnect, it starts using the wireless connection to talk to the server and then fails to reconnect, as the laptop is still using the wired Ethernet for all its network traffic.
The solution is to turn off AirPort when using a wired ethernet connection. By turning off AirPort, my SMB share stays connected and the problem does not happen. Apparently having an IP address for the wired Ethernet connection plus an IP for AirPort messes up the SMB connection. I just have to remember to turn AirPort back on when the wired connection is not available (like at home or elsewhere in my building). This could probably be automated with a launchd script that disables AirPort when Ethernet is available, and enables AirPort when it's not ... any takers?
Using ext3-formatted disks to create file-based iSCSI targets have one major drawback: They can only be read by another Linux machine with iSCSI. But what about attaching a pre-formatted drive as target?
Take a suitable Linux distro (eg. CentOS 5.1; it needs to have support for the Apple partition type in the kernel!) and install iSCSI Enterprise Linux (latest stable seems to run fine with Leopard). Attach the Mac-formatted drive to the machine, but do not mount it (you may if the distro has HFS+ support, but you don't need to). Let assume it's an external SCSI-RAID (or Firewire, USB) and is /dev/sda. You then create, in ietd.conf, a new target:
Depending on your server's hardware, a Type=fileio may give a better performance; you can simply try both out.
/dev/sda3 is the third Mac partition on the drive; you may have to find out which partition number is the correct one. Depending on the number of drivers (like for OS 9 support), it may vary up to sda5 or higher. Some versions of fdisk on Linux support Apple partition shemes, some not, but it might be a way to find out the right one. If your target is later mounted on the Mac and is unreadable and has only 48k ... then it's the wrong one.
Install an iSCSI initiator (Atto, Small Tree or the free globalSAN from SNS) on your Mac and connect to the target. It mounts fine and can be used just like a local disk. And if the server is down, take it back to any Mac with SCSI -- it's good to have the choice. A backup running on the Linux server itself may not be able to do a local backup -- or you can trust the HFS+ driver and mount the drive read-only.
Beware: iSCSI is quite new and many people had/have problems using it, but a drive shared like this can be used for TimeMachine.
If you have been attempting to follow the various guides posted on the Internet on how to set up the AirPort Express as a bridge using WDS and DD-WRT routers, you may be left wondering why your particular setup does not work even when all the settings are entered correctly.
However, these guides fail to realize that not all routers behave similarly when running DD-WRT. If your router has a Broadcom wireless chipset, then you're probably safe, since Airport Express als runs on Broadcom chip. However, if your router is Atheros-based, such as the D-Link DIR300, Airport Express would not be able to participate in the WDS network.
Assume you want to do some work on a remote Mac via 10.5's Screen Sharing, but you forgot to enable Screen Sharing before you left the remote Mac. You're now a good distance away, and apparently stuck. Fortunately, because the screen sharing system uses launchd to monitor its state, enabling and disabling is as simple as adding a file in the remote Mac's /Libary/Preferences folder. (Note that you'll need to be able to login to the remote Mac via ssh to run these commands on that Mac.)
$ cd /Library/Preferences
$ echo -n enabled > com.apple.ScreenSharing.launchd
To disable screen sharing:
$ cd /Library/Preferences
$ rm com.apple.ScreenSharing.launchd
If you have a Finder window open with the remote Mac selected in the Shared section, you'll even note the icon for Screen Sharing coming and going as you do this.
My work computer is behind a firewall that only allows connections to port 22. Even if it wasn't behind a firewall, since the documents may be sensitive, I would rather not transfer anything without encryption. I want to mount my user directory of my work computer to my laptop wherever I might be. This is relatively easy with .Mac and Back to My Mac in Leopard. If you don't have .Mac and Leopard, however, here is how to do it with one click without spending any money.
First make sure that the computer you want to reach has either a static IP address or has a domain name. If not, go to DynDNS (or similar service) and create a free account. Download DynDNS Updater to the computer you want to reach, and setup your domain name such as work.dyndns.org.
Next, fire up Terminal on your home computer or laptop from which you want to reach the work computer.
[robg adds: The remainder of this hint duplicates and combines information from some existing hints; in that way, it's something of a duplicate. However, I don't believe we've published a full walkthrough like this before. Keep reading for the detailed how-to...]
I recently bought a wireless IP camera (EcoLine by a company called Security-Center). Of course, all the software that came with it was Windows only. Nevertheless, I connected the camera over Ethernet with my Airport Extreme base station, did an address scan, and found out the IP address of the camera. I then pasted the IP address into Safari, and the camera's browser-based configuration client opened.
For full functionality, I would have needed ActiveX. Still, I was able to configure RTSP, HTTP, and dnydns.org settings using Safari. Then I opened QuickTime and opened the URL of my webcam:
rtsp://MYHOSTNAME.dyndns.org/live.sdp
Instead of live.sdp -- which is the default on my camera -- you can choose any other name, as long as you don't forget the .sdp suffix. This might be useful, especially if you have more than one camera. As expected, the live video of my driveway opened in a seperate QuickTime window, thanks to dyndns from anywhere.
This hint might also be useful for those who want to watch live streaming only supported by ActiveX, but who don't have access to a Windows computer.
I was trying to figure out a way to open a screen sharing connection to a particular server on my LAN from a Dock or desktop icon. Being able to do it by entering a vnc:// URI in Finder or Safari was okay, and the hidden Bonjour Browser was one step better. But when I accidentally dragged and dropped an entry from the Bonjour Browser to my desktop, guess what happened? It created an icon that I could double-click to open a screen sharing session!
This file is just a plist with a .vncloc extension that opens with Finder.app by default. It looks like this, if you want to create your own:
Assume you want to do some work on a remote Mac via 10.5's Screen Sharing, but you forgot to enable Screen Sharing before you left the remote Mac. You're now a good distance away, and apparently stuck. Fortunately, because the screen sharing system uses launchd to monitor its state, enabling and disabling is as simple as adding a file in the remote Mac's /Libary/Preferences folder. (Note that you'll need to be able to login to the remote Mac via ssh to run these commands on that Mac.)
