If you are a site administator there should be an "Admin" link should be shown in RAMADDA. This takes you to a set of Site Administration pages.

The main admin settings page consists of:

For information regarding SSL see the FAQ. The Hostname and HTTP port should be set. RAMADDA uses these when it creates an absolute URL in some content (e.g., a generated THREDDS catalog).

For information on the Server Registry settings see remoteservers.html.

Specify the RAMADDA administator email for when RAMADDA sends email to users. The Mail Server is the smtp mail server that RAMADDA can use to send email. If this is not defined then user's cannot reset their passwords via email.

10.10.1 Access
Under Site Access you can specify that only registered users are allowe to access the site or only site Administrators.

The anonymous uploads Max Directory Size is the maximum size of the files that are uploaded through the anonymous upload facility. This cap keeps rogue users from filling up the disk via anonymous uploads.

The Cache Size is the size of the cached files that RAMADDA generates (e.g., ftp files). The cache is in: <ramadda home>/tmp/cache

If you are running the Unidata LDM system on the server machine you can allow RAMADDA services to inject files into the LDM queue by specifying the path to the pqinsert program and the queue location.

The File System Access field under the Access admin section is the list of server directories that can RAMADDA can serve files from. For security any files that RAMADDA provides access to must be either in the locally managed storage area under the RAMADDA home directory or they must be under the directory tree or trees specified in this field. For example, when you have a harvester that does not move the files to RAMADDA storage then the directory you are harvesting needs to be listed here. Likewise, any Local File View entry needs to be listed here as well.

10.10.3 Display
The Display settings allow you to change the title of the repostitory, add a footer, etc. The Description is used when registering with external registry servers. While you can always change the HTML templates used the Logo Image Location and URL are a quick way to change what image is shown and the URL that is used when the logo is clicked.

The Translations field is a quick way to define new phrases to use in place of the default phrases that RAMADDA uses.

The Facebook Comments key allows you to integerate the Facebook comments facility. Contact RAMADDA support for more information.

If the Google Maps Key is defined then there is a Google Earth plugin display capability provided. You need to get an API key for each domain name and port you might be running RAMADDA under. The format of the admin setting is (one per line):

hostname1;API key1;premier_opts1
hostname2;API key2;premier_opts2
hostname2:<port>;API key3
The premier_opts is optional. e.g.:
  • If you are doing development on a local machine you can get an API key for "localhost".
  • If your organization is using the Google Maps API Premier, the key is left blank and you supply the information through the "premier_opts" parameter. See the Google Maps API Premier Developers Guide for more information.

This section allows you to restrict the different entry outputs available. For example, you can hide the Data views, the Calendar view, etc.

A RAMADDA repository has the ability to create new, self-contained "virtual" repositories. These children repositories are controlled by the parent repository but are fully self-contained RAMADDAs with their own database, file store and users. To enable virtual repository facility in RAMADDA you need to set the following property in either some properties file in the RAMADDA home directory or through the site Admin Settings form.
Once enabled and with RAMADDA restarted there should be a "Local Repositories" section in the Admin pages. This page will list all of the children repositories and their status and allow you to create new repositories. When you create a new repository you need to specify an ID (e.g. "testrepos"), and an admin account password. This results in a repository that can be accessed through the URL:
Web login session is not shared among virtual repositories but you should be able to login with the user name and password from the parent repository as well as with the account information specified for the new repository. Note, the children repositories themselves can contain virtual repositories. It is easy to move a child repository into its own RAMADDA server. First, from the Admin Local Repositories page stop the RAMADDA that you want to move. On the file system of the server under the RAMADDA home directory there should be a sub-directory "repositories". The RAMADDA home directories for each virtual repository is placed there (e.g., "repository_testrepos"). Simply move the virtual repository home directory to another machine and use it as the main RAMADDA home dir. Note, for space reasons, when moving the directory you can delete the plugins, resources, and tmp sub-directories. If you delete the plugins directory you will need to re-install the plugins on the new machine. You can also move a virtual repository into another RAMADDA as a new virtual repository. Simply copy (or move) the virtual repository home directory into the "repositories" sub-directory (create it if needed) of the target RAMADDA. Then, through the target RAMADDA's admin screen add the new repository. RAMADDA will note that there is already a home directory with a database, etc., and will use that instead of creating a new one.