Web File Manager FAQ

Can Rumpus allow users to lookup forgotten passwords?

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 "User Info" 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 "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.

What is the size limit for files uploaded via Web browser?

Rumpus does not limit the size of files transferred, and can handle file uploads and downloads of many gigabytes. Some Web browsers, especially those running slightly out of date releases, are limited to 2 GB or even less. When users need to upload large files, especially files over 2 GB, make sure the client is running the latest version of their Web browser, or have them use a dedicated FTP client like Fetch or Transmit.

How can I control what happens to files downloaded via the Rumpus Web File Manager?

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 "Actions" 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.

Can the WFM be customized for individual User Accounts?

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.

How can I extract my SSL Key from OS X server?

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 ensure 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.

Can Rumpus and Apache both be run on the same server, using the same IP address, and both on the default HTTP port (80)?

In short, it is possible, but it requires fairly advanced configuration of Apache. This procedure can be tricky, even for experienced Apache administrators. Also, this is actually a feature of Apache, not Rumpus, so while this FAQ lays out the basic approach, Maxum can't guarantee that we can provide all the answers to Apache setup questions.

Let's assume that you have 2 domain names, both of which resolve to the same IP address. Your primary Web service, at the domain name "www.acme.com", is serviced by Apache. Your Rumpus service, at "rumpus.acme.com", is serviced by Rumpus running on the same server.

Configure Rumpus to run on a non-standard Web port, say 8000. The Web port in Rumpus is set on the Options tab of the Web Settings window. Apache is then set to bind to the usual HTTP port, 80. In this way, all client requests, whether the connection is made to "www.acme.com" or "rumpus.acme.com", will initially be received and processed by Apache.

The trick is to configure Apache to act as a reverse proxy for the "rumpus.acme.com" domain, so that when a request is received for that domain name, Apache routes the request back to Rumpus running on the alternate port. For complete details on setting up Apache as a reverse proxy for a specific virtual host, see the relevant Apache or server documentation, but here is the general idea:

For Apache 1.X:

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

  <VirtualHost *:80>
     ServerName rumpus.acme.com
     ProxyPass / http://rumpus.acme.com:8000/
     ProxyPassReverse / http://rumpus.acme.com:8000/
  </VirtualHost>

For Apache 2.X:

  LoadModule proxy_module libexec/apache2/mod_proxy.so

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

A change also needs to be made to let Rumpus know it is being run behind a reverse proxy. In Rumpus, choose "Open Config Folder" from the "File" menu (in Rumpus 6.X and before, 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.

OS X Server Users:

OS X Server uses the Apache Web service, but uses special configuration files in the process. Changing the Apache config files directly may have inconsistent results. Try creating a virtual server in OS X Server, and then modifying the OS X Server config file for that virtual domain.

For example, to set up an alternate service using the "rumpus.acme.com" domain name, you would create a Web site in OS X Server called "rumpus.acme.com". Once you have done that, look in the folder:

  /Library/Server/Web/Config/apache2/sites

There you will find a file that includes the alternate domain name, like "0000_any_80_rumpus.acme.com.conf". In that file is a VirtualHost configuration block which can be modified to include the proxy directives shown above. Some of OS X Server's configuration options, like the "IfModule" and "Directory" blocks, can be removed, since the virtual server won't actually be processing files from the file system. Other config options, like ServerName and ServerAdmin, can be left as specified by OS X Server.

Here is an example:

  <VirtualHost *:80>
    ServerName rumpus.acme.com
    ServerAdmin admin@acme.com
    DocumentRoot "/Users/Shared"
    DirectoryIndex index.html index.php /wiki/ default.html
    CustomLog /var/log/apache2/access_log combinedvhost
    ErrorLog /var/log/apache2/error_log

    ProxyRequests Off
    <Proxy *>
      Order deny,allow
      Allow from all
    </Proxy>
    ProxyPass / http://rumpus.acme.com:8000/
    ProxyPassReverse / http://rumpus.acme.com:8000/
  </VirtualHost>

Remember to stop and start the Apache service (using OS X Server if you have customized the OS X Server config file) after making changes to force Apache to reload changes.

Why do some files display as generic file icons in thumbnail view directory listings?

The Rumpus server is unable to generate thumbnail images on its 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 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 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.

When I monitor or manage users via the Web, iPhone or FileWatch interface, why don't I see all user accounts?

There are several ways to view and manage user accounts and monitor user activity in Rumpus, including the Web admin interface, the iPhone application, and FileWatch. All of these tools are designed to allow you to create "sub-administrators" who can manage individual groups of users. For example, you might choose to have 3 other people in your organization who each can manage and monitor their own user groups, without seeing the accounts managed by other sub-administrators.

If you are unable to view all user activity or manage all user accounts, it is because your Rumpus user account is considered a "sub-administrator" account.

Administration groups are defined by the administrator's "Home Folder". An administrator will be able to view and manage any user account who has a Home Folder which falls within the administrator's own Home Folder. Put simply, if an administrator's Home Folder gives the administrator access to a user's content (the user's Home Folder), then that user is considered to be part of the administrator's group. Of course, administrators can view activity and manage the accounts of anyone in their group.

To set your own user account as the primary administrator, set your own user account Home Folder to "ROOT" by clicking the "Home" button next to the Home Folder field on the Define Users window. Any user account with a Home Folder of "ROOT" will always be able to view activity and manage the accounts of all users.

When using the iPhone app, there is actually a bit more to consider. The fundamental rule is that administrators will be able to view only those accounts which they are capable of creating. On the "Remote Admin -> Mobile App" tab of the Network Settings window, there are 3 choices to choose from that determine how a new user Home Folder should be assigned. Since that selection determines new user Home Folders, it also determines what user accounts an iPhone user will be able to see. Here's a breakdown of each option:

Set New User Home Folder To Default - In this case, new users created via the iPhone app will be assigned the default user account Home Folder, and when viewing user accounts via the iPhone app, you will see only user accounts who have that Home Folder assigned.

Make User-Specific Home Folder In Default - When this option is selected, new user accounts will be assigned a Home Folder that is a sub-folder of the default user account Home Folder, so again will see only user accounts who have a Home Folder that falls within the default user Home Folder.

Make User-Specific Home Folder In Admin's Folder - New users will be assigned a Home Folder that is inside the administrator's own Home Folder. This is the option you should choose if you need to be able to see all user accounts. In this case, iPhone administrators will be able to view user accounts whose Home Folders fall within their own Home Folder (unlike the first 2 options, where the ability to view accounts is based on the default user Home Folder). So, if the administrator's Home Folder is "ROOT", the admin will be able to view all user accounts.

© Copyright 2013, Maxum Development Corp.