I was fooling around with my old Color Stylewriter 4100 printer and some LocalTalk connectors, and found how to make it print from Tiger using AppleTalk PAP (Printer Access Protocol). Presently this printer is connected to my old PowerBook 170 using LocalTalk cabling. The PB 170 is running the Apple LocalTalk Bridge (2.1), and is also on my Ethernet network. This tip should also work with any of the physical LocalTalk/Ethernet bridges (Farallon, Asante) available used on eBay and elsewhere with an AppleTalk-enabled StyleWriter.
First, with the printer and bridge computer (or device) turned on and booted up, and your Tiger machine connected to the same network (Ethernet) with AppleTalk active on Ethernet (System Preferences -> Network), open Terminal on the Tiger machine and type atlookup. Note the printer entry, and AppleTalk zone. If you have a simple network, the AppleTalk zone will probably be *.
I have two LANS, each with their own OS X Server, that need to talk to each other through a low bandwidth, secure, dedicated connection. There are various ways to do this, but I opted for using a pair of EtherBridges, which are devices that bridge over a dialup modem connection. So, each server has three ethernet cards: one for the Internet (en0), one for the LAN (en1), and one for the bridging connection between the LANs (en2). The problem was how to configure a route such that traffic for the "other" LAN goes through en2. Note that I did not want simply to bridge the two LANs into a single subnetwork. I needed each to be its own distinct subnet, but with traffic routed between them.
After a bunch of research on the problem, I concluded that the OS X GUI configuration package simply doesn't understand about any kind of routing except a single default route. The traditional BSD way to deal with this problem is to insert code into rc.local, but if I added a route command there, it had no effect or a bizarre effect. I experimented with LaunchDaemons and StartupItems, but they also had no effect or the wrong effect.
To make a long story (several days) short, the trick here is that you must use an ifconfig command in the rc.local script, even though at a later point in the process, the GUI-specified interface configuration will be done redundantly. If you do not do this, the route command will fail, because there will be no device configured for the bridging subnet.
I need to mount shares when I am connected to the main wireless connection here at home. So I wrote a quick ruby script that will do this based on your network name, and mount the shares you have listed.
Make a file called auto_mount_shares, open in a text editor.
When trying to drag a folder to a Novell File Server from the Mac hard drive, a user received the following message:
Sorry, the operation could not be completed because an unexpected error occured (Error Code -51)
After some digging, the folder was failing once it tried to copy a file that had the # symbol in its name. This was replicated using three different users. Removing the # character fixed the problem and allowed the folder to be copied.
I, like many other users, have had the mysterious "Mac OS X wants to use keychain system" dialog box after each reboot, when AirPort tried to access the wireless network for the first time, that refused to accept any known password. There have been some users out there who solved the problem by simply removing the System.keychain from /Library/Keychains/. Some other users suggested creating a new System.keychain with a known password.
I didn´t feel comfortable using one of those solutions, because I had the feeling that there must be (1) a reason that there is a System.keychain, and (2) that it doesn't have a keyword that is known by the user. Digging a bit deeper into the system (BTW, I'm a designer and no programmer), I found out that the initial installation of 10.4 (and every subsequent update) contains a postflight script that will create this particular keychain. So my solution was quickly found.
You need to have admin-rights on the Mac you want to update using this hint. Then just:
Make a backup copy of your current System.keychain. In Terminal, type:
I've read a dozen hints on related topics, but haven't seen anything that deals with precisely this issue. I have an iMac at work and a PowerBook at home. I wanted to keep the two machines in sync, but without lugging the PowerBook into the office. I also wanted to do this without opening the Terminal.
My criteria meant that the obvious (but not necessarily easy) solution, rsync, was ruled out. Folks suggested rsyncX, psync, and Unison, but I was most convinced by the arguments in favor of Chronosync. Chronosync costs money, but it does exactly what I need it to: it gives me all the power and flexibility of rsync, but with a nice, polished GUI.
But Chronosync has one significant limitation: it can only sync two volumes that one can mount locally. All the Chronosync documentation (which is quite thorough, by the way) presumes that you have two locally-mounted volumes, either over a LAN or through FireWire, etc. But, you'll recall I didn't want to haul the PowerBook into the office.
I thought I'd have to drop my 'no CLI' condition and turn to rsync, but then I read this hint on a related but different topic, and found the suggestion from jctull (scroll down a bit) about how to use SSH Tunnel Manager. Thus, the solution to my problem was to do the following:
Use Tunnel Manager 2.0 to create an ssh tunnel from the PowerBook at home to the iMac at the office.
Set up Tunnel Manager (following jctull's instructions in the above hint's comments) to forward port 10548 on the powerbook to port 548 (afp) on the iMac.
Connect to localhost:10548, which mounts the iMac drive as an AFP volume on my PowerBook.
Launch Chronosync, set up the sync, and go from there!
This all seems simple enough, and is a breeze to use now that it's set up. But I was rather surprised that no one had mapped out any sort of simple instructions to sync two machines not on a LAN without using the command line. My next step would be to automate this process with an AppleScript, but as you can likely tell from above, I'm not much of a programmer. Any suggestions greatly appreciated.
I run a closed WPA2 Airport network (not out of poor neighbourliness, but due to New Zealand's backward broadband situation, with very restrictive and expensive data caps.) This is normally not an issue, my laptop identifies the network and logs on automatically, as it should. To do that, I set the Airport configuration in Network Preferences to "By Default, Join Preferred Networks," and under the Options button, "Automatically add new networks to the preferred networks list."
After recent changes to my system, I could not get it to join the network automatically. Each time, I had to type in the name of the closed network, and the WPA2 password, in order to get access. This is both a nuisance and a slightly increased security risk, so I was keen to get back to the automatic login. Everything in the network settings was apparently as before, the network was at the top of the preferred list, and I began to wonder if a recent Airport or System update (I'm on Mac OS X 10.4.5) had broken the previous functionality.
What turned out to be the problem however, was that I had changed the Airport network while trying to get a USB wireless adapter working with it. The change in the network password to a 13 character one for improved compatibility was not updated in the preferred networks list in the Network Preference Panel. So the automatic connection was still operating on a previous password. Once I manually changed it to the new one, everything operated as before. A minor issue perhaps, but the sort of thing that can be quite infuriating until you track it down.
Two previoustips addressed this issue in terms of the Keychain. This tip identifies the password issue in Network Preferences, and provides the needed fix.
I have a single label domain name that is the same as the name of the Forest. Try finding any information about the problems of a single label domain. I'll just say that the problems are numerous, vexing, and undocumented.
I don't know how much of the following is critical for the connection to AD, but I've worked so long and hard to get this working that I don't want to turn them off and on to try to break it. And given other posts about unpredictable behavior, turning them off and on may not even tell me which ones are necessary.
With the recent security threats to OS X, I thought it would be a good idea to be able to automatically configure my firewall based on the applications I have open. If no application is using said port, it's closed. So with a little help from bash and AppleScript, I now have an application that automagically scans for open applications and configures the firewall accordingly. Enjoy!
The D-link DWL 122 seems to very buggy drivers on OS X: when you unplug it while your Mac is on, it often crashes with a kernel panic. How can you avoid that?
Go to your System Preferences, then Network, then click Show and choose Network Port Configurations from the pop-up menu. There you can find "Ethernet adapter (en1)." That is your wifi dongle; uncheck the "On" checkbox, then click "Apply Now." Now you can unplug your dongle without any fear :)
Remember to tick it back to On if you want to use your dongle again. This hint is useful for other wifi dongles using the same chipset and drivers (e.g.: NetGear ma111).