The following is not mine, but I ran across it and it looks awesome. If you like the services .Mac provides, but would rather provide them yourself and you have a spare machine lying around, this how-to explains the steps required to do just that. I'm going to try it later tonight on an ubuntu server at home, and will post my findings in the comments.
[robg adds: Typically I would contact the author and request permission to repost their solution here, so we have it in the system. However, this particular how-to is quite long, very detailed, and contains lots of screenshots. It's also not for the faint of heart, as you'll have to do a fair bit of digging to find info, and then some configuration work. You're not just setting up a server that provides .Mac-like services, but you're setting it up such that the functions on your machine that use .Mac actually work with your internal server.]
At my work, we have a large number of SMB shares, and for some reason they stop showing up on desktops sometimes. If you look for them in Terminal, they are mounted, but they are not in the Finder anywhere. If this happens, here's one way to get them back.
Launch Terminal and type cd /Volumes
Type ls to list the directory's contents, and find the volume name in the list.
Type open volumename, where volumename is the name as shown in the prior output.
A new Finder window will open with the root contents of the volume you chose, and the icon will then appear in the Finder window and on the desktop (if you have network volumes showing on your desktop).
If your laptop is running unplugged and you need to conserve battery life, one way of saving power is to turn off AirPort. (You may also run into situations where you'd want to turn AirPort on or off as part of a longer script, such as to keep it from dying completely when putting a MacBook to sleep while Internet Sharing is enabled.) Although there seems to be no reliable way of turning AirPort on or off directly via the shell, it is possible to get around that by manipulating OS X's Locations with the scselect command.
First, create a new location called AirPort-Off in the Network preferences pane. With this new location selected, select Network Port Configurations under the Show pop-up menu, and deselect AirPort. Then select your previous location, which for most people would probably be Automatic.
Now, you can turn AirPort off by running scselect AirPort-Off and back on by running the last command, replacing AirPort-Off with the name of your normal location name. To assign a hot key to the command using a utility like Butler, create a simple AppleScript containing this one line:
do shell script "/usr/sbin/scselect AirPort-Off"
Then have Butler (or your app of choice) run that APpleScript. (With Butler, running a shell script containing only the bare command doesn't seem to work.)
A few days ago, a friend came by with his AirPort Extreme base station (AEBS) and his external USB hard disk. He was having problems getting the hard disk recognized and shared through the AEBS in a seemingly random way. The AEBS would correctly share the disk, until you would directly connect it to a Windows PC to transfer files. After that, reconnecting it to the AEBS's USB port would lead to an unmountable network share on the Mac, and an empty share on the PC (Windows XP SP2).
We thought of a formatting problem, so we first reformatted the 500GB disk as an HFS+ volume, and tried again connecting it to the AEBS. Transfers would work both ways from the PC and the Mac through the AEBS. But after connecting the disk directly to the PC and transfering files with TransMac, then plugging the disk back on the AEBS, we would get the same problem with an unmountable share (the problem wouldn't appear after connecting the disk directly to the Mac).
We restarted the base station several times using the AirPort Utility without success. Until, on a hunch, I decided to try unplugging the power plug from the AEBS, and then plugging it back in. After trying the same procedure several times, this appeared to reliably lead to the recognition and mounting of the shared hard disk.
Unfortunately, we didn't have time to test more scenarios (like reformatting the disk as FAT32), but the bottom line is: restarting the AEBS from the AirPort utility doesn't seem enough, so unplugging the power and plugging it back may be more helpful.
While looking for a way to disable Apple Remote Desktop and other services from the command line, I happened to be in /System » Library » LaunchDaemons. In my boredom, I opened ssh.plist in that directory, and find that Bonjour is a key. Anyway, skipping a long explanation and some inevitable tinkering, I figured out how to stop Bonjour from pointing out to the world (or at least my local network) that I have ssh enabled.
Be warned that while I have had no problems, I can not insure that you will not. This hint edits a system file, and messes with Bonjour, so think before you act. It also may take a system restart, in addition to undoing this hint, to re-enable Bonjour broadcasting of ssh and sftp. I would make a backup of /System » Library » LaunchDaemons » ssh.plist first, as we will be be deleting two strings from that file. (When I tried commenting them out, they disappeared after I stopped and restarted ssh.)
After you've made your backup, here's one way to edit the file:
sudo vi /System/Library/LaunchDaemons/ssh.plist
In the editor, delete these two lines:
They should be found around lines 22 and 23. Save the file and quit the editor. Then go to System Preferences » Sharing » Services, unlock it, disable Remote Login, and final re-enable Remote Login. You can check if things worked by using Bonjour Browser or some such similar app to be sure ssh/sftp no longer show up.
Lastly, to explain the plus in the hint title: A simple grep -ir bonjour . showed that eppc.plist, ftp.plist, and telnet.plist also had the Bonjour key. I don't use them myself, so this same trick may or may not work for those services, too.
I recently picked up an AirPort Express to stream iTunes to my luxurious Apple Hi-Fi. However, it seems to lose the connection periodically, which is annoying at a minimum. I searched high and low and couldn't find a script to address this issue, so here is one I whipped out.
What it does:
Checks to see what time it is.
If reasonable time, checks to see if speakers are there.
If no speakers found, announces a restart and restarts iTunes and clicks play.
Post to the system log as we go so we know the script ran.
It's a rather clunky way to fix the issue; a better way would be just to enter the secret command that iTunes is sending, but how do I trap that? I also have a script that will restart the AirPort Express. However, I have not found a need for it yet, since restarting iTunes (6.0.2) seems to fix the issue. For this script to work, your speakers need to be named "Speakers" or "Fred's Speakers" or "Pokey's Speakers" -- or anything else with "speakers" in their name. I used Cronnix and put this in a cron script (yes they still work in Tiger) and it runs every 15 minutes.
I was looking at the Wireless Options in the new Airport Utility to configure my Airport Extreme router. I noticed you could reduce the power output of the wireless. Since I have the router in my living room it sounded very appealing, especially since I have a new baby in the flat. I tried reducing it to 25%, but the signal was barely strong enough to work in the kitchen, which affected performance.
I recently followed the tips in this article to see if they would help at all. Changing the channel and implementing MAC filtering means I can now set my AirPort Extreme at 10% power, and I still get full strength signal everywhere in the flat. I also have fewer incidents where I have to manually rejoin my wireless router.
[robg adds: You might also want to set your AirPort up as a closed network -- it won't be visible to the casual user who happens to be located nearby, though this won't stop dedicated hackers from finding it. Note that you may have some devices that won't work with a closed network (I had an old audio appliance that simply failed to connect if the network was closed).]
I often use Personal File Sharing to move files between the various Macs here at macosxhints.com HQ. A typical scenario will have me connecting to the desktop machine from my MacBook Pro to move some files I've modified back to the main machine. At some point after that, I'll move back to the main machine and continue working, then put the main machine to sleep when I'm done. Later in the day, I switch back to the MacBook Pro, and notice that the main machine's share is still mounted. "I should eject that, since I'm done with it now," I say to myself, forgetting that I've put the main machine to sleep.
Blammo. As soon as I press Eject, the MacBook Pro enters what turns out to be a 12-minute cycle of uselessness. I get the spinning rainbow in every application, and keyboard and mouse input is ignored -- everything except clicking on an application's window to activate it. (Yes, 12 minutes -- here's the log file, with some comments.) But I cannot get the Force Quit dialog to show, I can't type in Terminal, and the machine is essentially a brick. Then, 12 minutes later, the system realizes that the connected server is no longer there, ejects the mounted share, and everything returns to normal (and some number of the keyboard and mouse inputs I've entered are then processed en masse, which can be entertaining to watch).
I've had this problem for quite a while, but only got serious about debugging it a week or so ago. With some help from Kirk, we figured out what was going on. On Kirk's machine, ejecting a sleeping share resulted in the Finder (and only the Finder) hanging for a minute or so. When we compared out network setups, the only real difference was that Kirk uses DHCP IP addresses while I use static IP addresses. When I ran the same test with my machines set to use DHCP addressing, the 12-minute hang vanished, and I saw the same behavior as did Kirk.
I don't, however, want to use DHCP (not for any good reason, of course; just personal preference). So I did some more experimenting, trying to find a cleaner way to exit this hang when using static IP addresses. What I found was that if I clicked on the share's name in the sidebar, I'd get the much nicer one-minute Finder-only hang, instead of the 12-minute total lockup. (As a side note, I did find a couple of possibly-useful prefs settings (afp_reconnect_interval [default: 10] and afp_reconnect_retries [default:12]) in the com.apple.AppleShareClientCore section of the .GlobalPreferences plist file, but modifying them didn't seem to have any effect on the 12-minute hang.)
So the hint here is two-fold: first, use DHCP if you do a lot of AFP share mounting, as you'll avoid the problem entirely. But if you do use static IP addressing, then do not hit the Eject icon for any sleeping shares -- just click on the share name instead, and you'll see a much nicer (and quicker!) timeout process.
If you own a Mac with an AirPort card, but don't own a wireless router, here's a way to put the AirPort card to use: use it to share your internet connection with your Wii. First, make sure you're connected to the internet (via something other than the AirPort card, i.e. Ethernet). Also, make sure AirPort is on. Then do the following...
Step One: Turn on Internet Sharing
Go to System Preferences, click on the Sharing icon, then click on the Internet tab.
Change the 'Share your connection from' pop-up to Built-in Ethernet.
Under the 'To computers using' section, check the AirPort box.
Click Airport Options, and enter an easy name such as wii in the Network Name box.
OPTIONAL: Use any password that fits your settings (i.e. 128 bit WEP requires 13 characters).
Click OK if you're on the AirPort Options screen.
Click Start in the Internet Sharing panel.
Step Two: Gather Information
Open Terminal.app and type ifconfig en1.
In the output look for: inet xxx.xxx.xxx.xxx netmask ....
Take note of the IP address associated with the first inet, negating values after the # (mine was 10.0.2.1; yours may be different).
Type dig. Near the bottom of this output will be SERVER: followed by an IP address. This will be the DNS server address that you will use for your Wii.
OPTIONAL: Use an ASCII/hex converter (such as this one), and enter you password in ASCII to get the %-separated hex-equivalent. This should be 26 hex characters for a 13 ascii character password using 128 bit WEP.
On the Bluetooth System Preferences pane's Settings tab, click on the Bluetooth Device Name string to reveal details like the MAC address, adapter version (someone please confirm this?), and model/make.
Note that I'm using a USB Bluetooth adapter. If you are one of the lucky ones to have Bluetooth built-in to your Macs, your mileage might be better.