Rumpus 5 requires Mac OS X 10.3.9 or later. Any Mac OS X system capable of running OS X 10.3.9 will generally make a fine Rumpus file server, since Rumpus' RAM and CPU requirements are minimal. Typical DSL, T1, cable modem, and even faster Internet connections will normally be the limiting factor in file transfer performance, not the server itself. You should, of course, be sure to have adequate disk space available on the server to store the content that will be uploaded and downloaded to and from the server.

Both the Rumpus application and server daemon are provided as Universal Binary executables, and run natively on PowerPC and Intel based Macs.

Rumpus can provide FTP (or WFM) access to most types of external hard drives or remote volumes mounted on the server Macintosh's desktop. User home folders can be set to folders on external hard drives, or even remote servers mounted on the desktop, but the more common way to give access to these volumes is through Finder Aliases.

The usual, recommended, way to set up an FTP server is to create an "FTP Root" folder, and then create sub-folders within that folder for individual user home folders. Generally, your FTP Root will be on the Mac boot volume, which guarantees clean, consistent access to every FTP user's top level home folder. To give access to remote volumes, simply select the volume in the Finder, make an alias to it, and then drop the alias into the FTP home folder of any user that should be given access to that volume. When the user logs in via FTP, they will see the volume (named according to the name of the alias) as they would any other folder in their home folder.

Of course, you don't need to provide access to an entire volume. Aliases to individual folders on remote servers, external hard drives, and the boot volume can also be created and dropped into any user home folder.

Most servers will run Rumpus all day, every day to provide 24/7 FTP access for their users. To have Rumpus automatically started when the server is booted, open the "Install Server" window and check the "Launch Rumpus Service At System Startup" checkbox. Note that this will not start the Rumpus control application, only the Rumpus service, when the computer is turned on. In fact, the Rumpus service will be started even if no user logs in to the computer.

The "Launch Rumpus Service At System Startup" checkbox is more than a simple preference setting. When the box is checked, a startup script (and associated "plist" file) is saved to the folder "/Library/StarupItems/Rumpus/", and when it is unchecked, the script is deleted.

No, a static IP address isn't required, and Rumpus works fine when your external IP address is dynamic. A static IP address does simplify things, and is recommended when available, but dynamic domain name services such as DynDNS and No-IP can be used to direct users to your server, even when your public IP address changes.

Every computer connected to the Internet has an address. The address has the form "192.168.1.100", that is, four numbers seperated by "dots" (periods). These addresses can be temporary, and assigned each time a computer logs into the Internet (dynamic addresses) or permanently assigned to the computer (static addresses). IP addresses are assigned by your ISP, in either case. Dynamic addresses are assigned each time users log in so that a handful of addresses can be used by a large number of people, in turn. Static addresses are assigned to one person alone, and are permanently associated with an individual computer.

When possible and cost-effective, a static IP address is preferable. If you don't have a static address, or don't know how to configure one, call your ISP. Normal residential Internet accounts usually don't include a static IP address, so you will most likely need an extended or business-oriented account. Again, only your ISP can help you with this.

If your server is connected using a dynamic address, the address will change every time you log in to the Internet. People wishing to connect to your server will not know the address to connect to, unless you tell them each time they need to connect. The solution to this is to obtain a domain name that maps to the current IP address of your server. The domain name will remain constant, and end users will always be able to enter the name to connect to your server. The name will simply resolve to your current IP address at any given time, so that users will always be connected to the right server. In addition to DynDNS and No-IP, other services are available. Google "Dynamic DNS" for lots of options.

The use of names, rather than IP addresses, for referring to a server is handled by DNS (Domain Name Service). If your company already has a domain name registered (let's say, "acmewidgets.com"), you can populate any domain name you wish within that space. For example, you could have "files.acmewidgets.com" or "uploads.acmewidgets.com" mapped to your Rumpus server. To set this up, contact your ISP or registrar (the company through which you registered your domain name). Adding another DNS record is usually very quick and easy.

Note that the name "ftp." (as in "ftp.acmewidgets.com") is also commonly used. However, since Web browsers will commonly assume your server is FTP only, they may not connect in the most efficient way when a user supplies a name that begins "ftp.". If you do define a domain name that begins "ftp.", consider populating a second record like "files." or "uploads." to use for Web access.

Domain names work very much like your local phone book. You use a phone book to find a phone number given a person's name. The domain name system (DNS) allows Internet clients to find an IP address from a domain name. Your Web browser, for example, doesn't actually connect to "www.maxum.com". It uses a domain name server to convert "www.maxum.com" to "67.38.123.181", and then connects to that address.

Domain names are unique, and must be registered. Again, your ISP can help you with this, or you can use one of the registration services such as register.com. Once registered, your ISP or registration service will handle adding your name to the domain name system so that your static address is returned whenever a client asks for your domain name.

Rumpus actually includes 2 servers: HTTP and FTP. HTTP is the "Web" protocol... All "Web" sites are run by HTTP servers. FTP stands for "File Transfer Protocol". FTP is an entirely different protocol from HTTP, and defines a mechanism for 2 computers to transfer files. The Web allows you to specify how pages will be displayed to a user, accept input from a user (via forms), and do everything else we typically associate with the Web. FTP does not allow you to specify an interface to be shown to a user, or present any information in a generalized way... It is strictly for transferring files, and the interface seen by the user is completely up to the FTP client being used. The advantage of FTP is that it is a complete protocol for managing files, allowing the client to create and transfer folders, delete and move files, and more.

Most Web browsers include elementary FTP services, though they usually are very basic and often buggy. After all, they are first and foremost Web browsers, which means they were designed to work within the HTTP protocol. Dedicated FTP clients like Fetch, Transmit, WS_FTP, CuteFTP and others do a much better job with FTP.

When you enter a URL that begins "ftp://" you are telling the client (a browser, for example) that they should connect via FTP. URLs that begin "http://" are Web URLs, and tell the client to connect using the Web protocol.

Since Rumpus includes both FTP and HTTP servers, you can usually connect using URLs that begin either "ftp://" or "http://". In practice, you should choose the protocol that is best suited to the client software being used. In other words, if you are connecting from a Web browser, then form the URL so that it begins "http://". When connecting via FTP client, begin the URL "ftp://". (Actually, most FTP clients do not support HTTP or any other protocol, so a full URL is typically not required and you should just enter the server's address.)

It is very common for people to have problems transferring files with a Web browser via FTP. This is, in fact, exactly why the Web File Manager exists. Rumpus has been optimized to be as broadly compatible as possible with all FTP clients, including Web browsers, but there is a limit to what can be done from the server-side to compensate for poor FTP client implementations. When using a Web browser, it is therefore almost always best to connect via HTTP. For true FTP access, recommend to your customers and users that a real FTP client be used to connect to your server.

Any computer file is actually nothing more than a series of numbers. What gives these numbers meaning is how they are processed. An image file, for example, needs to be opened by a graphics program, an audio file by a media player, etc. Matching files to the appropriate application, based on the file type, is performed by the system. When a file icon is displayed incorrectly, or the file isn't opened by the correct application when it is double-clicked, a problem with the file's type has occurred.

When the system is unable to match a file to the correct application, you can do this manually by dragging the file icon onto the application. This forces the selected application to be launched and then explicitly told to open the file. However, in many cases, it is desirable to have file types preserved so that files will open correctly when downloaded to a client computer, or on the server after upload.

When a file is transferred across a cross-platform network (the Internet), it looses it's Mac-specific information, which includes it's Finder info and resource fork. Finder info includes the file's type and creator codes, which the traditional Mac OS uses to match files to the applications that can process them.

To preserve Finder info and resources, the file needs be be transferred using MacBinary encoding, which Rumpus fully supports. Unfortunately, no Web browsers support MacBinary, but well-behaved, traditional FTP clients, like Fetch, do.

So, to transfer a file with it's resources and Finder info, you need to use a MacBinary capable FTP client, and make sure the file is sent with MacBinary enabled.

Most modern file formats no longer use resource forks. In these cases, just make sure that the filename has the correct suffix. OS X uses either Finder info or a filename suffix to match files to applications, so if you use the correct filename ending, the file should still be handled correctly after transfer, even if it's Finder info is lost.

For files uploaded to the server, Rumpus will automatically apply the Mac OS type and creator codes to an uploaded file based on its filename suffix, using the table on the "File Types" window. When files are downloaded to a remote client, the "Content-Type" is sent to the Web browser, which in most cases allows the browser to select an appropriate helper application to process the file (or process the file itself).

Another option for preserving resource forks is to compress the file before transfer as either a ".zip" archive or some other stuffed format. As long as the tool used to archive the file supports resource forks, the resources will be compressed into the archive file, and will be restored when the file is extracted at the destination.

For more details, see the "File Transfer Basics" article in the Rumpus package.

Yes. In Mac OS X 10.5 and later, Apple has moved to an application-based firewall. This means that rather than configure the firewall to allow specific ports, you'll need to specify the Rumpus service as an allowed application.

Open the System Preferences, and choose the "Security" panel, then switch to the "Firewall" tab. Next, click the "Add" button just below the list. A standard file selection sheet will be displayed.

The Rumpus server daemon is located in a folder not normally shown in the Finder, so you'll need to enter the path to the Rumpus configuration folder manually. Enter Command-Shift-G (for "Go to folder") and then enter the path "/usr/local/Rumpus". The file selection listing will display the contents of the Rumpus configuration folder. Select the "rumpusd" daemon file, and click "Add". The firewall setup should now include the "rumpusd" application, as shown below.

Your OS X firewall is now set to allow Rumpus to act as a server for incoming connections.