There may be times you want to temporarily turn off your Internet connection: for example (long reason short), some HTML-based spam messages can be used to verify your e-mail address just by viewing the images contained therein.
If you're using AirPort, the answer is simple: turn off the AirPort connection, which is normally what I do. However, with my G4 tower at work, which uses a wired ethernet connection, I couldn't do that.
So, what you can do instead is to create a new network location (I called mine "No Access") and enter in bad or garbled information. Or, in my case where at work I have a static IP, I made the new location try to use DHCP (which would fail). Then, when you want to turn off your network connection, just go to the Apple menu, Locations menu, and select No Access, and you're kicked offline until you want to go back.
Under iTunes 4.0, a lot of people started using music sharing to access the music on their home computers from work. Sadly, iTunes 4.0.1 removed this feature due to piracy concerns. Fortunately, you can re-enable iTunes sharing across subnets with the freeware Rendezvous Beacon.
After downloading and launching Rendezvous Beacon, create a new Beacon with the following values:
Beacon Enabled: (checked)
Service Name: (descriptive name)
Service Type: _daap._tcp.
Port Number: 3689
Text Record: (empty)
Enable Host Proxy: (checked)
Host Name: (rendezvous name of your home computer)
IP Address: (ip address of home computer)
Now you'll be able to access the iTunes shared music on your home computer through your work computer's iTunes as if they were both on the same subnet.
Note 1: I feel that iTunes, because of its five-connection limit and the need to authorize computers to play purchased music, is a very weak platform for pirating music. This hint is intended simply for restoring a very useful feature that was removed by iTunes 4.0.1 because of Apple's fears of music pirating. Please don't ruin this for the rest of us by trying to iTunes for pirating.
Note 2: With Rendezvous Beacon you can use a similar process to publish services via Rendezvous that are served up by non Rendezvous enabled servers. This is potentially very useful for a net admin.
[robg adds: Unlike hints on defeating copy protected songs, which clearly violate the infamous DMCA, I don't believe there's anything inherently illegal about accessing your own music from another location. However, if I'm wrong, I guess this article (but hopefully not the site) will soon vanish in a puff of legal smoke.
The other reason that I feel OK about publishing this one is that there are a ton of other ways to do the same thing. For instance, search macosxhints for "streaming," and you can read several hints on how to set up your own streaming server to send your music to another location. Also, an anonymous hinster pointed out a command line program called mDNSResponder that does the same thing.
People that are truly interested in pirating music are going to use one of the P2P applications, not a measly little iTunes five-connection-limited application that requires an additional third-party application with which to actually steal the music...]
I was researching the issue of using PowerPrint for Networks on OS X for a while, and found the answer on allosx.com. Since I looked for so long, I thought I'd post this here. Credit goes to Rob Crestani as shown on the original page. Essentially it boils down to this:
Select Option -> Add in Print Center.
Device-URL should be:
pap://*/[AppleTalk Printer Name]/Printer_Adapter
Where [AppleTalk Printer Name] is the name that appears under the Chooser in OS 9 when the PowerPrint device driver is selected (don't enter the brackets). The crucial part is Printer_Adapter, which selects the PowerPrint device.
Printer model: my printer does HP LaserJet Emulation. This very common. Your mileage may vary.
When I was reconfiguring the IP address on my OS X box to move from one network to another, I noticed that my netmask was 255.255.255.1 instead of 255.255.255.0. I hadn't noticed any problems before. But every time I tried to change it to 255.255.255.0, it would go back to 255.255.255.1 when I hit the Apply button. Everything seems to work still, except I couldn't log into my .1 router even though I can ping it.
To my surprise, when I changed the netmask to 255.255.254.0, the Mac accepted the change. And now when I changed it to the correct 255.255.255.0 netmask, it stayed!
This was one of the more bizarre network strangeness I've seen. Hopefully, the hint will save some headaches out there. Note: I'm running OS X Server 10.2.6. Don't know if the anomaly has been seen elsewhere.
[robg adds: If anyone has any thoughts on what might cause this problem, please post them!]
The Cocoa framework indeed has a lot of peculiar features. For example, you don't have to write IP addresses like everyone else does. Every segment of an IP address is a number between 0 and 255. (You could also say that they are a byte each). This can be translated into a number. So if you take the IP address of macosxhints.com, 126.96.36.199, and do this calculation:
You get 3,475,821,262. Now if you enter that number (without the commas -- 3475821262) into a Cocoa based browser (Firebird and Safari will do, Internet Explorer won't as it's a Carbon app), you will be at the macosxhints.com homepage. It seems to work in Cocoa based apps. I tried it with Safari, Firebird, and several CLI apps like traceroute, ping, telnet and ftp.
Practical? Maybe, but mostly as a gimmick. Of course, it can save you some typing. Anyone have any ideas for optimum usage?
We use LinkSys BEFSX41 router / gateway / firewall / VPN appliances to interconnect the LANs at three sites via VPN. Since two of the sites have DHCP-supplied WAN IP addresses, we needed a way to notify the other sites when the LinkSys' WAN IP address changes. This is required so the Remote Security Gateway's IP address for the VPN tunnel can be updated.
Since the addresses don't change that often, I wrote a script to detect any change and send email to the interested parties. If you are interested, that script is available for download (download 2KB script), and usage is explained in the script comments.
I wound up making this process harder than it actually is, so this hint is to help y'all from making the same mistakes I made. Here's the deal ... you're not at home, but need info on your Mac that is subnetted to an AirPort Base Station that has a (static) IP address.
What you'll need to know: The usual IP address the Base Station assigns to your machine (ie 10.0.1.2), which is easily found in the network system prefs. Using the AirPort Admin Utility, log into your Base Station and "Show All Settings." Click on the "Port Mapping" tab, then click "Add."
For Public and Private port, put 22 (the standard SSH port number), and for "Private Address," put in the usual IP address (ie 10.0.1.2) assigned to your machine. Click on "Update" in the lower right corner, and wait while your Base Station reboots.
Once it does (I had problems doing this remotely from a friend's Mac, so you might want to do this at home), you'll be able to log into your subnetted machine by doing the following:
Once you give your password, you're in! Using the -p command line option of ssh, and modifying the port mapping in the AirPort Admin Utility, you should be able to get access to all your wireless machines. Hope this is helpful!
[robg adds: I haven't tested this myself, though I should as it could be quite useful at times.]
Basically, this is a very easy little hint, but it saves me some time over a network here at home. If you're on a network, simply disable View -> Show Icons while in column mode. Browsing network-mounted volumes will now be much quicker.
I didn't see this listed anywhere ... but it's kind of useful for me anyways.
This isn't a revolutionary tip -- it just puts together several well-known tricks into something useful. Today I was downstairs with my iBook, and I wanted to play some music. Thanks to iTunes4, I can play all the songs in my desktop G4's library via the wireless network. That's great, because now I can keep everything in one place, and the G4 can be the music server for the entire house.
But two problems: The G4 is upstairs in my home office, and iTunes wasn't running. he easy solution is, of course, for me to get off my ass, trudge up the stairs, call up the dock, and start iTunes. Then go back downstairs and enjoy my music on the iBook. But, like any good computer geek, I'm lazy. So instead I did this:
Use ssh to log on remotely to the G4.
Give this command: open -a iTunes
Upstairs, the G4 starts up iTunes.
Log off the G4, and enjoy the music on the iBook.
In step one, I could have used telnet instead of ssh, if the G4 were set to allow it, but ssh is more secure, of course. And of course, the library will only be available if I've previously set the G4 to share its music library. Hopefully this tip will be a useful reminder to anyone as lazy as I am: You can log on remotely and use the open command to start up any app you might need.
[robg adds: Yes, it's basic, but useful and not (near as I can tell) published here before in this general form. I do a similar thing to launch VNC (a remote control client), as described in this hint.]
I have all my iTunes data on a linux NFS server, which I had previously used with a Windows box via Samba. The new iMac uses NFS to access the same data store. I found changing ID3 tags to be very, very slow compared to the Windows box. It turns out that write performance seriously lagged. smb_fs mounts performed well, but could not be automounted, so I ended up tuning the NFS settings.
The critical factor that affected performance was the number of nfsiod threads. Adding more threads means that more simultaneous NFS operations can occur at once (including read-ahead and write-behind operations). To increase this value, simply edit the file /System -> Library -> StartupItems -> NFS -> NFS, and change the line that reads:
nfsiod -n 4
Replace the 4 with 8 or more, followed by rebooting or manually killing and re-running nfsiod. You will notice an increase in throughput when writing large files. To test the speed, run the following command before and after the change:
time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
Going from 4 to 8 nfsiod threads resulted in write speeds going from 700k/sec to over 3.2mb/sec! Further tuning can be found by reading the Linux NFS How-To Performance Section.