This option is only available to the admin user, or users belonging to the admin group. The administrator can perform day-to-day configuration, maintenance and monitoring through, this interface.
The Server screen is classified into different sections as described below:
db by default)
and a fresh database will be created next time the server is started.
The status of the system scheduler is shown on this web page. In particular, you can view any jobs that are in progress. You can also review what triggers are loaded by the scheduler and when they last fired and will next fire. You can also force the scheduler to reload the triggers, though this is only necessary if the trigger files have been manually edited. If you have edited the trigger files using the Schedule Designer (which is included in the Remote Designer package) then the triggers will be automatically reloaded by the scheduler when you save them.
Every user of Elixir Repertoire Server should have a unique logon name and password. This gives access to the Server via the web interface (through a browser), through Elixir Repertoire Remote and through the variety of client tools that Elixir provides. Use of specific filesystems and files is granted based on user name and/or group.
To create new user, click on the Create User at the bottom of the Elixir Repertoire
Users list. User name and password are required in order to create a Repertoire user successfully. You
should usually also assign the user to one or more groups. You can edit a user by clicking on the user
name in the list. You can change the name, password, groups etc. If you leave the password field
blank, then the password will not be altered. You cannot change a name that would result in duplicate names.
You can change the name of the admin user to anything you like, and even then change another user to be called
admin. However, internally all users and groups are identified by id, and user id = 1 is the admin user,
regardless of the actual user name. For this reason, you can delete any user, except user id = 1.
Rather than assign access rights at the user level, it is often more convenient to combine users into groups and assign rights to the group. Each user can belong to any number of groups. Any user who is assigned to the admin group will have the ability to administrate the server. Just like with users, group names can be changed, so group id = 1 is the admin group, regardless of what the group is actually called. For this reason, you can't delete group id = 1.
There is another special internal group "*" which has id = 2. This group is used to represent all users. Every user created automatically belong to this group. When describing access rights, for example in filesystems or secure .access files (described in the next section) you can use an asterisk (*) rather than enumerate every single user and/or group. The "*" group cannot be viewed or edited directly as it is managed by the system.
A filesystem is a collections of files such as datasource, report templates and dashboards that users can view over the web. An administrator has the option to create, edit, compact and delete filesystems, and also to grant access to certain groups. Compact will clean up the directory by removing all the backup files.
To create a filesystem, select the Create filesystem link at the
bottom of the Repertoire Filesystem list. Display Name and Configuration are required.
Every filesystems on the Elixir Repertoire Server must have unique name.
Administrator can assign the group(s) to have access to the filesystem.
There are five types of filesystem available: Dbfs, Jar, Jdbc, Local and Secure.
The Database filesystem (Dbfs) stores files in an SQL database within the server. The files in Dbfs support properties and you can manage user access to individual files or folders. The files and folders have three sets of permissions, for the owner, the owning group, and others. Each permission set may contain Read (r) and/or Write (w). When a file or folder is created it will inherit the access rights of the parent.
The configuration field contains the name of the store to use as store=[name] i.e.
store=local. The configuration can be left empty, in which case the default store is local.
A Dbfs /User filesystem is automatically created when the server is first
initialized and is given appropriate permissions for each user to store their
personal files. You can create additional filesystems of type Dbfs as necessary.
A Jar filesystem stores all files and folders in a Java archive format, that is typically a file with a .jar or .zip extension. Files in a jar filesystem are read-only, so this is a useful way of deploying reports and dashboards so that you are certain they cannot be modified. The configuration field for a Jar filetype should provide the full path to the archive file. Remember this file must be on the server, so it is a server path name you are providing.
The Jdbc filesystem is deprecated in 7.2 as it is replaced by Dbfs, which has additional access rights control. You can still access the files stored in any Jdbc filesystem but will no longer be able to create new filesystems of this type.
A Local filesystem stores all files in a directory tree on the server. This is often the easiest filesystem to use for single-server solutions as the storage mechanism is completely transparent. You can use all your regular file-handling tools for manipulating the directory tree. The configuration field for a Local filesystem should provide the full path to the root of the directory tree. Remember this tree must be on the server, so it is a server path name you are providing. Also, ensure you are running the server with a restricted set of permissions, (eg. by creating a new user called repertoire and running the server from that user account) to prevent access to the entire server filesystem.
A Secure filesystem is an extension to the local filesystem and used when the file access needs to be limited access to specific users and groups. A secure filesystem required a special file called .access to be placed inside each restricted directory of the filesystem, which allows the administrator to give different access privileges to named users and groups.
A .access file has this format:
#This is a comment read:finance,sales write:elixir write:admin
Each file can have multiple read and write statements, one per line, in any order. Granting write access automatically grants read access. You can use either user names or group names and access is only allowed if explicitly granted. You can also use the special group "*" to allow access to everyone.
All logs from the server log directory are listed and can be inspected through the browser interface. The primary log is the activity log, which lists all session activities (logon and logoff) as well as generating and rendering actions. More detail is provided in the server log; this provides a fine-grain view of the system, which is primarily for debugging. The jetty log file lists all file accesses.