For those who don't know, LittleSnitch is a great application that lets you block outgoing network connections. It's very useful to stop apps (such as trojan horses) from "calling home." The problem is I often log into home via ssh, and want to use stuff like curl, for which I do not want to define a specific rule and would rather have LittleSnitch ask me every time.
Say I want to install something remotely using Fink; I can't, because there's no way to tell LittleSnitch to let curl connect to the mirror. So I came up with a little AppleScript UI script to fix this...
I use VNC on an XP box at work to connect to my Mac at home. The speed isn't too bad, but I've found a very simple (and once you know, completely obvious) way to increase the connection speed. I had all manner of fancy images used as desktop backgrounds on my Mac. Last night, I switched the background to a flat colour only, and the increase has been almost astronomical.
Like I said, a very simple and obvious hint.
[robg adds: For those who don't know, VNC is a way to control one computer's GUI from another location. RealVNC is the official home of the software, but they don't offer a Mac server (just PC/Unix servers and clients). Redstone Software, though, makes an OS X VNC server called, simply enough, OSXvnc. There used to be quite a few Mac clients, but the only one I'm aware of with any recent activity is Chicken of the VNC (CotVNC).
You may see another speed boost if you tell your VNC client to only display 256 colors. In CotVNC, you do this via the Connection -> Connection Profiles menu option, then click on the Colors tab. Even if you can't stand 256 colors, try Thousands instead; you should still see an increase in rendering speed.]
Ever wanted to send text snippets from one machine to another via the Terminal? Save this XML code to a file named pbcopy.plist in your user's Library -> LaunchAgents folder (note that you'll probably have to create the LaunchAgents folder).
Next, execute this command in Terminal (or just logout and login):
Now you'll be able send any text over the network right to the clipboard on this machine via nc (netcat) or bash, like this:
$ echo test | nc -w1 18.104.22.168 2224 [or]
$ echo test >/dev/tcp/22.214.171.124/2224
Note that the second example is a bash feature and may be disabled on some systems. In both examples, replace 126.96.36.199 with the IP address of the receiving Mac (the one running the XML code), and make sure your firewall allows access to port 2224.
This is very convenient, but also very insecure. However, if you add the following lines to the pbcopy.plist file, between the dict tags in the Listeners section, then it will listen on only the loopback interface:
Once that's done, you may access the service from a remote machine on 127.0.0.1:2224 if you ssh there with this option in the .ssh/config file:
RemoteForward 2224 127.0.0.1:2224
This one is a default for all my ssh connections, because very often I need to transfer a lot of text output to my local machine from many kinds of unixes. Unfortunately, Terminal's cut-n-paste can't handle this without breaking lines or truncating the text to the size of the scroll buffer.
Another trick -- if you installed SubEthaEdit and its command line tool called see (/usr/bin/see), you may put that program in the .plist (instead of /usr/bin/pbcopy), and then the editor's window will pop-up with the text content that was sent.
[robg adds: I tested this, and it worked quite well ... very well. I was able to accept text from anywhere on the net, as tested by friends in The Netherlands and Montreal. I suggest that if you implement this, you use the ssh restriction, as it does seem somewhat insecure. To remove the agent, use launchctl unload ~/Library..., then delete the file.]
Some places, like universities, require that you be connected to their VPN servers in order to do stuff like check email through a non-webmail client or access certain resources they give you. My school uses the Cisco VPN Client. So I just leave the VPN connection up and running constantly. But sometimes I want to be able to connect to my home machine from on-campus machines. Normally, this would require that I write down my VPN IP address, since there's no existing mechanism for updating a DynDNS hostname with an IP address assigned by Cisco's VPN Client. That is, until now.
Here's a quick sub-hint. If you don't want to deal with the Cisco VPN GUI being open in your Dock all the time, use the command line client. Open your Terminal and type screen and press Enter. This will take you to a new screen session. Press Enter again after reading all about the wonderful screen utility. At the new prompt, type vpnclient connect [profile_name]. Enter your username and password to connect. Once you've established the connection, you detach the screen session by pressing Control-A and then Control-D. The first keeps the session active in the background, and the second detaches the screen into its own background process. You can then quit the Terminal. If you want to check back in with your screen session, type screen -r.
Okay, on with the real hint. I started with the DNS updater utility in this hint, written by Robert Miller, and modified it (view source) to grab the IP outputted by the command line VPN client. Most of the commented-out code was my experimentation with Keychain integration. Unfortunately, unlocking the Keychain requires a graphical context, which this utility does not have when run as a periodic process with cron or launchd. (I will cover setting this up later in the hint.)
I'm running a few services on my Mac at home: Timbuktu, for remote access to my Mac while away from home; accessTunes, for music streaming; ssh shell access; and I'm playing around with the Apache web server now.
Normally, all of these services work fine. I've configured my gateway/router to do all of the appropriate port forwarding. I've also recently set up a dyndns.org account so that I have a domain name for my home system, making access much easier.
However, all of these services used to go to hell when I started up my VPN connection from home into my office network. I could still access these services using other computers on my home network, but from the outside world, nothing would work. This was particularly frustrating if I'd left the VPN running by accident, got to work, wanted to connect home, and couldn't get in -- especially to do the one thing I'd really like to do at that point, which is to shut down the VPN.
I finally figured out what was going on: All of these services were happily listening on their assigned ports for incoming connections on both my LAN IP (through which all WAN access arrives) and on the VPN-assigned IP. But, when these services sent replies, they tried to reply back through the VPN to every client with a non-LAN IP address -- in other words, a request comes in one pipe, but the reply to that request get sent out down a different pipe, and never gets received. What I really want to happen is for all replies to go to the LAN IP except those which are replies to clients with IP addresses associated with other systems on the VPN.
Under Tiger, this previous hint, to create a custom ipfw setup to write log entries to the /var/log/ipfw.log file, doesn't work -- it seems that program blocks inside syslog.conf are ignored.
However, the solution is to modify (just a little bit) the script you use to launch ipfw at startup (if you are using a custom firewall configuration, you know what and where that is). The modifications are to set the verbose parameter to 2, and to launch the ipfwloggerd daemon.
This is the code that accomplish the goal (some details may vary, depending on your setup):
I bought a Belkin ADSL modem and 802.11g router which came bundled with a USB wireless dongle. I wanted to use it with my iBook, which would take an original AirPort card, but why waste what I already have? After much searching and trying many possible solutions and modifiying countless plist files, I stumbled across a forum with a link to a driver download page for a list of wireless cards, and includes a driver for OS X 10.4 -- scroll down to the Mac section and find the USB driver for 10.4. This link (492KB) should download the current driver, dated August 28, 2005. There are drivers for 10.3 there as well.
I installed it and it worked the first time -- although I did need to switch off Tx Burst mode in the Advanced settings, and turn off IP6 in the Network System Preference. Enjoy!
I use PPPoE on an ADSL connection which is limited only by the modem sync speed (ie: no data rate capping by the ISP, on the downstream at least), and I wanted to optimise the MTU to get the best throughput. The consensus seems to be that the optimal MTU is 1454, based on the fact that 1492 the maximum possible, and 1454 is the highest value less than this which doesn't end up with any padding bytes in the last ATM cell. An ATM cell is the basic transfer unit over a DSL link, and they are all fixed length, padded out to this length if the packet doesn't end on a cell boundary.
I tried configuring the 1454 value using a couple of techniques mentioned on macosxhints, but they didn't seem to have much effect, at least not on the downstream packets. A little network tracing showed that Mac OS X PPPoE was still negotiating an MTU of 1492 with my ISP. So I did a little digging around and came up with the following solution...
I have figured out how to send email hyperlink files to both Windows and Macs users at work. These files comes off a linux file server; the Windows users are using 2003 Exchange servers, and we have various Mac users. The hyperlink file in the email that you send to Mac users is different than the hyperlink file that you would send to a Windows users. In the end, however, both Windows and Mac users are able to click on a hyperlink to open a file off the server.
DISCLAIMER: Even though this works for me, it doesn't necessary mean that it will work for you. Success depends on the file server, Exchange server, ports and privileges, syntax, etc. This hint provides clues on how to set up hyperlinked file such that you may be able to send them to both Macs and Windows users via email. You will probably have to experiment a little (or a lot) to get this to work for you.
This hint is an evolution of another hint, which I had a hard time getting to work. You can read it for the rest of the detail, but the short story is that it allows you run a full remote X11 desktop session in a window on your Mac.
The longer story is that it probably won't work, because your Mac probably doesn't have the same X11 fonts installed as does the remote server. The older hint actually addresses this, but the explanation is confusing, and it only works if there is no firewall between you and the server. The fix is to forward the TPC port of the X font server over the SSH session, so that your local machine can actually talk to it. Here is what the entire setup looks like:
localhost% ssh -L7100:localhost:7100 -Y user@remotehost
(in another Terminal window)
localhost% xset +fp tcp/localhost:7100
(back in the first window, after it has ssh'd into the remote host)
remotehost% Xnest ":1" -geometry 1280x810 -query localhost
You have to have the ssh session open, with the port forwarding active, before you will be able to add the remote font server to your local font path. And you have to have the remote server's fonts in your font path before it will be possible for the remote desktop session (CDE on Solaris in my case) to start up.
One of the problems I had with the old hint was that it said to do xset +fp tcp/ip.of.remote.host:7100 and I thought he meant "use the tcp/ip address...", when actually the prefix tcp/ is really part of the syntax. The other problem is that it wasn't clear where you were supposed to run the xset command, or for that matter why you'd be tunneling X in SSH at all if there wasn't a firewall in the way.