A tip published back in December of 2000 explained how to set up anonymous FTP using the command line to create directories and copy files to various locations. Yesterday someone submitted an anonymous hint regarding a couple of shell scripts which automate the process.
Being somewhat leery of anonymous hints about setting up anonymous FTP, I downloaded the scripts and looked through the code. There are two included scripts (a setup script and a remove script) and neither one does anything malicious - you are never asked for your root password (it just makes sure you have root privileges before running), there are no commands that pass info to any outside URL's, etc. I have not actually tested the scripts (as I use CrushFTP for my FTP needs), but they seem to mirror the commands used in the previously published tip.
After you download the scripts, place them in your home directory and run the "anonftp" script with root privileges (check the included Read Me for more information). To remove anonymous FTP, run the "delanonftp" script with root privileges.
These scripts are hosted on a server with a dyndns address, which indicates it may be an individual machine that could come and go somewhat regularly. This may be the cause of the problem if you get an error when attempting to download the scripts. The URL that is hosting the scripts is http://hamburger.dyndns.org, in case you'd like to try hitting the main page as well.
ApleTalk Filing Protocol (AFP) root login can make it more convenient to remotely administer OS X boxes.
There's a property in NetInfo, found in the path config -> AppleFileServer -> allow_root_login, which serves this very purpose, and which is set to 0 by default. You can set it remotely to 1 locally using NetInfo Manager (or remotely using niutil; you need to kill and restart the AppleFileServer process for the change to take effect).
[Editor's note: I would imagine this is set to off by default as enabling root login via AFP does present some security issues if your root password is ever compromised. A hacker that discovers the root password will have the ability to login remotely at the root level. With the switch in its default setting, the hacker would need physical access to the machine in addition to the root password. So by changing the switch setting, keep in mind you are removing one layer of security ... at least, that's my view of it. Someone please correct me if I'm wrong.]
There are several tricks for sharing a USB printer on a Mac network, using Applescript, or using UNIX tools like Ghostscript, lpr printing, etc, but these are not well suited for novices. This note describes a hardware trick that lets you use at least two Epson printers as sharable network printers on a LAN. This trick may work with other printers, but I have no way to test that.
Basic idea: Get a print server that does parallel port to ethernet conversion, enable the AppleTalk protocol in the print server, then print to the "USB" printer as an AppleTalk printer, with the print server making the printer's parallel port function as an AppleTalk connection. So, the way you share a USB printer on a LAN is that you don't even use the USB connection! Most USB printers also have a parallel port connection.
For those who have to calculate subnet masks and available ip addresses given an ip address and netmask, check out a free command line utility which will do all the math for you. Feed it an ip address and decimal subnet mask or cidr mask and it calculates the network address, broadcast address, first and last available ip's and the net mask. This little gem is a real lifesaver for network admins. Check it out at :
I've been trying for the past several months to get IP Routing working to no avail. Today I tried geeRoute, and still couldn't get it working. It then dawned on me that I needed to (in addition to geeRoute's instructions) also include the address for my dns when configuring the remote computers.
I just did a name server lookup on my online computer (nslookup www.whatever.com) to find out the ip of my dns server. Plugged that in on a client computer and it works great!
In response to a thread in one of the Apple fora, I've made a quick web page that tells in simple language how to use fetchmail to pull down your email so you can filter it with procmail, but still read it with the Mail application. This lets you use procmail's incredibly powerful filtering capabilities even if you aren't running a mail server. It will even work well with a dialup account.
[Editor's note: I can't say I've tried this one yet, but I hope to shortly. This looks like an easy to follow recipe for getting your own personal spam filter up and running.]
If you are mounting multiple NFS exports from the same server and you are having trouble dealing with the naming convention, use NetInfo to create multiple hostname entries for this server.
For instance, I have an MP3 export and a backup export on my Linux 7.2 machine. I mounted the MP3 export first, and the mount was named servername. Then, I mounted the backup export, and the mount was named servername-1. My iTunes library would break if I mounted the exports out of order.
To alleviate the situation, I fired up NetInfo Manager and duplicated the entry for '/machines/servername' and renamed it to '/machines/servernameMP3' and now there is no conflict between NFS mount names.
Firenet is a solution to create a computer to computer network via Firewire. This solution was avalaible for OS 9, but with slow transfer results. The OS X version is supposed to give results as good as a Gigabit Ethernet transfer. You can download a free trial version for OS X, which allows 30 minutes of FireNet functionality per reboot.
This may not be the most advanced tip in the world, but then again, it may not be obvious to everyone who uses OS X. I know it wasn't obvious to me, and an email exchange with Michael G. today convinced me that I was not alone in my confusion. Hence, this hint...please skip ahead if you're an advanced UNIX user; this is probably a "no brainer" to most of you in that demographic.
Everyone probably knows that OS X includes SSH, a secure remote connection command-line tool. If you have more than one Mac and want to securely connect from one to the other at the command line, SSH is the program of choice. You enable this in the GUI (in the Sharing prefs panel, Application tab, Allow Remote Login), and then connect at the command line with "ssh -l username hostname".
There are a number of authentication schemes to make sure you're who you say you are, and if you implement SSH correctly on both machines, you can connect from one OS X box to another without entering a password, but still have a totally secure connection.
If you don't yet know how to do this, and would like to learn (along with a bit of a primer on SSH's security system), read the rest of the article.