Yes, Rumpus can allow users to request that their password be e-mailed to them, automatically.

For this function to work, you will need to make sure that each user's e-mail address is entered on the "Options" tab of the "Define Users" window. Next, create a new Event Notice that specifies a mail server through which Rumpus will be able to send e-mails. The "Mail To" address will be automatically replaced by Rumpus when sending password reminders, so you can set it to any convenient address. (For testing purposes, it's a good idea to simply supply your own mail address.) Enter the server administrator's e-mail address as the "Mail From" address, so that users can easily reply to the password reminder e-mail if they have additional questions. Also, be sure to set the "Subject" to some easily recognizable mail subject, such as "Your Rumpus Password".

Open the "Custom Message Body" sheet and choose "Forgotten Password" from the "Event Type" menu. This will create a simple default message body, which you can then customize to meet your needs. The text in the message body is what will be sent to the end user as the body of the forgotten password reminder e-mail.

Finally, with the Event Notice complete, open the "Web Settings" window and flip to the "WFM Options" tab. Turn the "Enable Forgotten Password Lookup" checkbox on, and choose the Event Notice you created for forgotten password reminders from the pop-up menu.

The WFM Login page will now include a "Forgot Your Password?" link, which will allow users to request that their Rumpus user account name and password be e-mail to them automatically.

Most modern Web browsers are limited to 2 GB for a file upload, though some may have trouble with smaller files, depending on available memory or other factors on the client computer. Most browsers should be able to easily handle files that are several hundred MB or more. So, depending on the browser and resources available on the client computer, several hundred MB to 2 GB is the limit.

For larger files, have the client connect via either FTP or WebDAV, both of which are designed to handle large file transfers.

Yes, using the Drag & Drop Uploader applet built into the Rumpus WFM, users can upload multiple files or entire folders with a single click.

To enable the Drag & Drop Uploader, open the "Web Settings" window, flip to the "WFM Options" tab, and choose either "Enabled" or "Default" from the "Drag Uploads" pop-up menu. When drag uploads are "enabled", users can choose to use the Drag & Drop Uploader from the "Upload ... Files" menu on the upload window. When drag uploads are selected as the default, then the Drag & Drop Uploader is used by default.

For complete details, including information on important restrictions to using the applet, see the "Web File Manager" article in the Rumpus package.

Rumpus offers several options that determine how a file should be sent to the end-user's computer or displayed when the user clicks a file link in a Rumpus directory listing. It is important to understand that while Rumpus can serve files in different ways, exactly how the file will be processed is entirely up to the Web browser in use. In other words, minor variations in how different browsers actually accept, process and display files are possible. With that understood, the very large majority of modern Web browsers in use today will properly handle files as indicated by the Rumpus server.

On the "WFM Options" tab of the "Web Settings" window, you can choose how Rumpus should deliver files for both the filename link (the link represented by the filename itself in directory listings) and the alternate link (represented by the download icon on each line in the listing). The options are: "Standard Link", "Download Link", "New Window", "Content Wrapper" and "Download Page". These options are described on the "Web Settings" Help page, in Rumpus, but the best way to see how these different link styles function is to try them yourself. Simply open a Web browser, log in to your Rumpus server, and click the filename link for a sample file, using each of the available "Filename Link" options.

Yes. In Rumpus, on the "WFM Appearance" tab of the "Web Settings" window, define a unique "domain" for each needed appearance. Colors, the logo, fonts, etc. can then be customized for each domain to define the look you wish to apply to each user account. On the "Define Users" window, flip to the "Options" tab, and select the appearance desired for each user account you wish to customize.

There are actually a couple of ways to do this.

The traditional way is to enable the "ANONYMOUS" user account, with the download privilege enabled, and the "Always Prompt For Login" option in Rumpus off. With your server arranged this way, you can simply place files in the ANONYMOUS directory, and send the file's URL.

In some cases, however, you may need to keep the "Always Prompt For Login" option enabled, or not want to enable ANONYMOUS access. In this case, you'll need to use an "Auto-Login URL" to automatically log the user in and begin the transfer. An auto-login URL begins with the simple URL to the file. The easiest way to get the URL is to log in to the Rumpus server via the Web File Manager, using the user account of the user you'll be sending the message to. Navigate to the file, and select it, and the browser will show the file's full URL in the location box at the top of the window. Now just copy and paste the URL into the body of an e-mail.

Finally, add "?login=username:password" to the URL, which allows the URL to link directly to the file, bypassing the login window when the user connects. For example, an auto-login URL that links directly to a file might look like this:

    http://www.yourserver.com/SomeFolder/TheFile.jpeg?login=bob:12345

For additional details on auto-login URLs, see the "Web File Manager" article in the Rumpus package.

Signed SSL certificates can be purchased from a number of companies on-line, including well-known authorities such as VeriSign and Network Solutions, as well as value-priced authorities like GoDaddy and RapidSSL. In order to obtain a signed SSL certificate, you will need to create a "Certificate Signing Request", or "CSR". Maxum is not an authority on SSL, does not provide SSL certificates, and does not recommend any particular authority. For the most part, you should direct questions about obtaining a certificate to your chosen provider.

With that said, creating SSL certificates is not hard, and the software to do it (OpenSSL) is thoughtfully provided by Apple by default in OS X. In the steps described below, replace "NAME" with a recognizable name for your certificate files, such as the domain name of your server. You do not have to create the certificate on the server on which it will be used.

1. Open the Mac OS X Terminal.

2. Create a new directory to save your certificate files:

    $ mkdir SSLCerts

3. Move into the directory you created:

    $ cd SSLCerts

4. Make the certificate file (don't forget to enter the certificate file name in place of 'NAME'):

    $ openssl req -new > NAME.cert.csr

5. Answer the questions when prompted. Here is an example session:

    Using configuration from /System/Library/OpenSSL/openssl.cnf
    Generating a 1024 bit RSA private key
    .....++++++
    ....++++++
    writing new private key to 'privkey.pem'
    Enter PEM pass phrase:
    Verifying password - Enter PEM pass phrase:
    -----
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [AU]:US
    State or Province Name (full name) [Some-State]:Illinois
    Locality Name (eg, city) []:Crystal Lake
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:Maxum Development Corp.
    Organizational Unit Name (eg, section) []:Sales
    Common Name (eg, YOUR name) []:www.maxum.com
    Email Address []:info@maxum.com

    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:

Be sure that you enter your server's domain name as the "Common Name". This is very important, as browsers will check the common name to make sure it matches the host name they requested.

6. Create the key file (again, enter the certificate file name in place of 'NAME'):

    $ openssl rsa -in privkey.pem -out NAME.cert.key

At this point, you have created the private key file ("NAME.cert.key") and a Certificate Signing Request ("NAME.cert.csr"). The "privkey.pem" file is your private key, encrypted with your pass phrase. Be sure that your private key files stay private, safely tucked away where you (and only you) can get at them.

7. Send the Certificate Signing Request ("CSR" file) to a Certification Authority. Be sure the signing authority is a root CA that will be recognized automatically by the Web browsers you wish to support.

The following steps will allow you to extract the private key when running OS X 10.5 or later using Keychain Access.

Execute the following command in the terminal to open Keychain Access with root privileges:

sudo /Applications/Utilities/Keychain\ Access.app/Contents/MacOS/Keychain\ Access

Note the spaces and other special characters. Copy and paste the command into the Terminal to assure correct entry.

In Keychain Access, select the System keychain, expand your certificate and select the private key.  Click on Export, or use Shift + Command + E to export the key.

Give your output file a name, select a location and select Personal Information Exchange (.p12) as the file format.

Provide a password and verification of the password and press OK to export.

Quit Keychain Access.

Next, convert the export from the encrypted p12 file into a .key file.

In terminal, change directory to where you exported the p12 file, then execute the following command:

sudo openssl pkcs12 -in name.p12 -out name.key

You may be asked for a password several times. Enter the password you supplied when exporting from Keychain Access.  Name.key contains both the certificate, and an encrypted private key.  In order to extract the private key use:

sudo openssl rsa -in name.key -out nameprivate.key

After supplying your password, the private key will be saved in plain text, ready for import into Rumpus.

For those familiar with Apach configuration files, yes, you can configure a server so that users can access both the Rumpus WFM and another Web site both running on the same computer, without specifying an alternate port number.

In the examples shown below, it is assumed that you have alrady set up an Apache Web server running on port 80, and have installed Rumpus and are running the WFM service on port 8000. Be sure that both services are working correctly, even though access of the Rumpus WFM requires the ":8000" port number in the connection URL.

The first step is to populate a second domain name that points to the same IP address as the primary name for the server. For example, if "www.acmewidgets.com" resolves to your server for primary Web access, a second name of "files.acmewidgets.com" might be used to refer to the Rumpus service. (For Web access, domain names that begin "ftp." are not recommended, as some Web browsers will assume this means that they should connect via FTP. A name that begins "files.", "uploads.", or something similar is better for accessing a Rumpus server via Web browser.) Configuration of domain names is done via DNS, so contact your registrar or ISP if you need help populating the new domain name.

Next, you will need to configure Apache to run as a reverse proxy for the Rumpus domain name. The configuration depends on your version of Apache. For Apache 1.X, the configuration will look something like this:

  LoadModule proxy_module       libexec/httpd/libproxy.so
  AddModule mod_proxy.c

  <VirtualHost *:80>
     ServerName files.acmewidgets.com
     ProxyPass / http://files.acmewidgets.com:8000/
     ProxyPassReverse / http://files.acmewidgets.com:8000/
  </VirtualHost>

For Apache 2.X, the configuration is a bit different, as shown here:

  LoadModule proxy_module libexec/apache2/mod_proxy.so

  <VirtualHost *:80>
    ServerName files.acmewidgets.com
    ProxyRequests Off
    <Proxy *>
      Order deny,allow
      Allow from all
    </Proxy>
    ProxyPass / http://files.acmewidgets.com:8000/
    ProxyPassReverse / http://files.acmewidgets.com:8000/
  </VirtualHost>

Once you can connect to Rumpus on port 80, even though it's really running on port 8000, you need to make one more change...

In Rumpus, open the "FTP Settings" window and click "Open Config Folder". That will expose the file "Rumpus.conf". Open that file in any text editor and add:

  WFMThruProxy YES

Save the file, then stop and start the Rumpus service to force the change to be saved. This change will cause Rumpus to drop the ":8000" from internally generated URLs, so that the Rumpus WFM will direct users to the standard Web port, even though the Rumpus Web service is running on port 8000.

The Rumpus server is unable to generate thumbnail images on it's own, because as a daemon process it doesn't have access to graphical services of the system.  So, when a thumbnail image needs to be generated, the Rumpus server hands the job off to the the Rumpus application, which uses OS X system services to actually create the thumbnail image JPEG.

So, while the Rumpus application doesn't generally need to run for the server to function, this means that it does need to be running in order for thumbnails to be created any time new files are uploaded.

There is also a difference in the system services available with which to generate thumbnails.  In OS X 10.4, image processing services exist but are limited to fairly basic image file types.  In OS X 10.5, Apple introduced QuickLook, which Rumpus takes advantage of to allow thumbnails to be created for many more file types.  In fact, QuickLook plug-ins, installed on a Rumpus server, will be used to create thumbnails in Rumpus, so that your server's ability to display thumbnails can be extended by installing plug-ins for the file types stored on the server.

To test to see if Rumpus is able to generate a thumbnail image of a particular file type on your server, use the "Generate Test Thumbnail" button on the Thumbnails tab of the Web Settings window.  If a suitable thumbnail image can't be created, a system update may be required (especially if you are running OS X 10.4).  If the server is running OS X 10.5 or later, search the Web for a QuickLook plug-in for the file type in question and install it, then retest.

Finally, note that Rumpus stores thumbnails so that it doesn't have to regenerate them every time a directory listing is served.  If default file icons have already been created for files in certain directories, you will need to signal Rumpus to rebuild images in those folders.  To rebuild images, log in to the Web interface under a user account set with the "Administrator" privilege, move into the directory in question, and choose "Rebuild Images" from the "Thumbnail Actions" pop-up menu.