I've tried to search the internet for a way to remotely trigger a torrent download from my iPhone, but there wasn't one. So I came up with this solution, which uses two different email accounts (one to send, another to receive), an iPhone, Mail, AppleScript and Transmission.
Note that this was originally published here, but I am the author of the hint. I thought this hint was necessary as the iPhone isn't capable of downloading and attaching torrent files to email messages, as is described in this older hint.
The idea behind this hint is very simple:
Copy the URL of the desired torrent.
Using a secondary email account, send the torrent link via email to the primary email with a preset Subject which will activate a predefined Mail Rule to launch an AppleScript.
The AppleScript will launch Transmission/uTorrent to open that URL and download the file.
What the AppleScript does is copy the URL in the body of the email message, launches Transmission/uTorrent, opens the URL, and starts the download.
I've used LittleSnitch for some years now and consider it a must-have. Short explanation: LittleSnitch is a network filter that watches your applications for outgoing connections (interesting how many applications establish connections to Google, by the way). Perhaps I'm a little paranoid, or maybe you like it as well.
In any event, some months ago I tried GlimmerBlocker, a software proxy between your browser and the internet with the ability to filter ads on websites, manipulate websites, and much more if you have a little background knowledge on how the web works. Something I also can't live without after using it for a while.
By accident, I discovered that LittleSnitch and GlimmerBlocker can't really coexist (at least if you are using Safari, because it uses the system-wide proxy setting as do all other applications). When you use GlimmerBlocker, all web traffic will be redirected to GlimmerBlocker, and GlimmerBlocker will be the outgoing connection LittleSnitch catches. So, it's no different if you're surfing websites with Safari, Mail is checking for emails, or eyeTV is looking for updates: LittleSnitch will pop up with "Glimmer Blocker want's to connect to...".
Before I was able to tell LittleSnitch to allow Safari all connections, but Mail to only allow connections to gmail.com (to not load any images in emails), but no longer once GlimmerBlocker is installed.
If you want to use LittleSnitch and GlimmerBlocker together, read the rest for my workaround, but be warned: Please do all of this only if you have some background knowledge of the network preferences and Apache. You may harm your network preferences and kill the internet on your machine if you don't know what you are doing here!
I encountered an issue with a mounted SMB shared drive, where users have always put their files using Tiger or Leopard without any issues. Some software (in this case, ADI Chart) uses the resource fork to store information. In Snow Leopard, SMB mounts are set to use the xattr (extended attributes) feature instead of ._ files for storing the resource fork (a nice change; less clutter).
Unfortunately, this method is not backwards compatible, so our other users are unable to read files uploaded by 10.6, and our 10.6 users cannot read any files already on the server (uploaded by pre-10.6 systems). So, we need to disable this new feature.
It turns out to be related to the 'NTFS Streams' feature of SMB mounts, so if we disable those, then all is well. To do this globally (per machine), we need to create /etc/nsmb.conf, or add the streams line below to the [default] section if the file already exists:
I used Terminal to make this change: sudo vi /etc/nsmb.conf.
I wrote a bash script that will find the current IP address of the WAN port on an Airport Extreme (and possibly other wireless routers) from the command line. It also works on a Linux-based computer, if you have the package net-smnp installed.
Go to the Advanced settings in your AirPort configuration, and select the Statistics tab. Make sure that 'Allow SNMP' is checked, and note the 'SNMP Community String -- it can be changed, but I would just keep it at public. Save your settings if they've been changed.
In the script below, the variable SNMPKEY needs to be changed if the 'SNMP Community String' is anything but public. You can also pass it from the command line if you wish. Here's the script:
if [ $# = 1 ] ; then
set -- $(netstat -nr | egrep '^0.0.0.0|^default')
set -- $(snmpwalk -Os -c "$SNMPKEY" -v 1 "$ROUTER" ipRouteNextHop.0.0.0.0)
set -- $(snmpwalk -Os -c "$SNMPKEY" -v 1 "$ROUTER" ipRouteNextHop.$4)
Back when 10.5 came out, this hint about enabling the screen sharing Bonjour browser was quite popular. Unfortunately, Apple disabled this very useful feature at some point during 10.5's life cycle, and it doesn't work in 10.6, either. In the course of my travels through the submission queue and Macworld's Mac Gems columns, I've come across a couple of possible replacements for this functionality.
First, there's Screen Sharing Launcher, an open source app that lets you add local computers to a list of available servers. When you want to screen share with another Mac, you just launch Screen Sharing Launcher instead, then select the desired machine.
This is a relatively new project, and it's not yet feature complete -- for instance, you can add machines to the list, but not remove them via the GUI. To remove them, you can edit the preferences file (with any pure text editor) directly; it's named net.curby.ScreenSharingLauncher.txt, and located in your user's Library » Preferences folder.
The other solution, and the one I've been personally using, is ScreenSharingMenulet, which is a faceless application that adds a new icon to the menu bar. Local hosts will show up automatically in the menu, or you can manually enter a host and add it to the My Computers section of the menu. Dan Frakes covered this app in an earlier Mac Gems column. The site's home page also lists two hidden preferences for controlling the display of IP addresses and the number of recent servers in the menu.
If you're aware of other replacements for the Bonjour browser, please list them in the comments...
After upgrading from Leopard to Snow Leopard, my MacBook would randomly stop resolving DNS names on my local network; most often occurring after awaking from sleep. The only way to "fix" this problem was to reboot. To add to the frustration of needing to reboot often, my Mac Mini continued to function without any of these troubles on the same network after being upgraded to Snow Leopard.
Symptoms included pings that would fail, I couldn't point my browser at web sites hosted on local servers, NFS mounts failing, and other general mayhem. Interestingly, while the MacBook was experiencing the problem, I'd run nslookup or dig on the DNS entry in question at a Terminal prompt, and it would return the correct information.
My network has a Fedora 11 box acting as a server with BIND DNS and DHCP running on it. Originally, I'd been publishing both my BIND and internet router as primary and secondary DNS servers respectively via DHCP. After removing the internet router as a secondary DNS, leaving only the BIND DNS, my MacBook magically began to work again.
I don't know the actual root cause and your milage may vary depending on your network setup.
Since Google announced their new free public DNS service, there has been a lot of talk about the speed of various DNS.
If you'd like to find the fastest DNS for your location, use the free Namebench, which tests well-known DNS as well as your regional DNS.
I had been using OpenDNS, but it turns out my ISP's DNS is 53% faster!
[robg adds: The test can take a while to run, and on my machine at least, I wasn't able to use the net while it was running -- lookups kept timing out until the test was over. The end result, though, is quite useful.]
In the past, people have submitted hints on how to get their Macs to start internet sharing automatically at boot. All of them are either editing files in hidden directories or creating a StartupItem to do the task. Most people may not want to edit files that are for the system, and Leopard and later versions of OS X use LaunchDaemons, not StartupItems to run scripts or executables at boot.
I created a LaunchDaemon plist based on the composition of the iStat Server's LaunchDaemon plist to run the InternetSharing executable automatically at boot. Here's what it looks like:
To install it, just copy the plist file into /Library/LaunchDaemons. The next time you reboot, the Internet Sharing option should already be turned on (once you're fully logged into a user account). The end result is identical to the older hints, but uses the new LaunchDaemon implementation rather than editing system files or installing a StartupItem.