The home of the Clarens RPM packages is at http://hepgrid1.caltech.edu/clarens/. In the following paragraphs the installation procedure is described using manual (interactive) and automated methods.
wget -q -O - http://hepgrid1.caltech.edu/clarens/setup_clump.sh |sh
wget -q -O - http://hepgrid1.caltech.edu/clarens/setup_user.sh
$opkg_root/etc/rc apache2 start|stop|restart
https://my.server.name:8443/clarens/for an encrypted connection.
Startup problems are reported on the terminal when the server is started, or
recorded in the log file at
The information below describes the procedure carried out by the setup shell scripts for clump, and is provided for completeness. If you are not comfortable with typing in commands in a terminal, please use one the above automated methods instead.
eval $(/opt/openpkg/etc/rc --eval all env)
It might be useful to add the following to your login scripts to avoid having to type in the above every time the environment is used:
rpm -i *.rpm
/opt/openpkg/etc/rc apache2 start
$opkg_root/etc/apache/httpd.conf. The format and meaning of options in this file is explained in detail at the web pages cited above, but the default configuration used by Clarens deserves some explanation.
If the user installation procedure was used, the server will run as the same user that did the installation, since normal users are not able to change process ownerships and run applications as other users than themselves. In this case changing the User and Group directives will not have any effect. Except producing an error message in the logs!
For a superuser installation the port numbers may be lower than 1000, with defaults of 80 and 443 assigned to the HTTP and HTTPS protocols by convention.
$opkg_root/etc/clarens-config/httpd/clarens-server-default.conf. For more information on the meaning of the options in this file, the mod_python documentation should be consulted. In general it should not be necessary to change this file.
There may actually be several of these files for different Clarens installations running under the same Apache server.
In order to make changing these parameters easier, the Clarens server package
contains an application called clarens-server-config. This application
takes care of creating a configuration file. By default the configuration file
is stored in
Figure 2.3.2 shows a screenshot of clarens-server-config in action. The section labeled Main server configuration shows the configuration parameters and their current values. To change the value of a parameter, use the up and down cursor keys to move the cursor to the chosen value and fill in the required text. Moving the cursor to one of the [Help] buttons and pressing Enter will bring up an explanation of the option in question.
Just as with the main configuration, all add-on modules can have their own sets of parameters. To change a module's parameters, move the cursor until the module name is highligted and press Enter. You will be presented with a list of options and Help values analogous to the main server screen.
After the configuration is changed it can be (and should be!) saved by pressing
Enter on the Save Config option. The option values are saved in the
The main server options are saved in the file config in that directory, with a subdirectory for each module also containing its config file.
The format of the config files consist of lines, each with comma separated fields for the option internal name, option value, option external name (displayed by the configuration application), help string, and the keyword INTERN or EXTERN. The latter values are written to a final cofiguration file named clarens_config.py that can be accessed by Clarens at runtime. INTERN values are only accessible at install time. Examples of such internal configuration values are the Apache server version and the Apache configuration file location.
Each group consists of two lists of DNs for the group members and administrators respectively. Group administrators are authorized to add and delete group members, as well as groups at lower levels. The group structure is hierarchical because group members of higher level groups are automatically members of lower level groups in the same branch.
The example in Figure 2.2 demonstrates the top-level groups A, B, and C, with second level groups A.1, A.2, and A.3.
A more concrete example might be to define groups CMS, Atlas, LHCb, and Alice, then for CMS, to define CMS.USA, CMS.CERN, CMS.UK, CMS.Germany. At the third level, one might define CMS.USA.Caltech, CMS.USA.UFL, CMS.USA.FNAL. Management for the latter three groups may then be delegated to the institutes themselves, thereby implementing a distributed trust model that has lower maintenance overhead as well as being more representative of the real organizational structure.
As a further optimization, the hierarchical information in the DNs may also be
used to define membership, so that only the initial significant part of the DN
need to be specified. DNs are structured to include information on the country
(C), state/province (ST), locality/city (L), organization (O), organizational
unit (OU), common name (CN), and e-mail address (Email). An example DN issued by
the DOE Science Grid CA is
/O=doesciencegrid.org/OU=People/CN=John Smith 12345
for individuals and
for servers. To add all individuals to a particular group, only
need to be specified as a member DN.
Since version 0.5.0 the Clarens server enforces access control on methods accessed by clients based on user distinguished names, as well as groups of users.
The access control list (ACL) for the echo module in the above
example can be specified using methods in the system module, or
bootstrapped using a file in the same directory as the
An example to illustrate:
The first tuple in the access list has an empty string as its first member, signifying that this ACL is to be applied to all methods in this module, unless overridden by a specific method ACL later. the second member The second member of the tuple is a list consisting of
In this case the allowed DNs and groups lists are evaluated first, before
the equivalent denied lists. That means that if a group or DN is present in
the allowed and denied lists, the allowed list will have preference and the
DN or group will be allowed. Groups can be created using the methods in the
The way that distinguished names (DNs) ar evaluated in the above lists
deserve special mention:
If a substring of the DN is found it is considered a match. E.g. the
DOEGrids CA issues certificates with DNs of the form
/DC=org/DC=doegrids/OU=People/CN=Joe User 12345
If access needs to be granted to all DNs issued by this CA, simply add the
following to the allowed list:
Or if all DNs issued to people by this CA needs to access this module, add
The ACL in the above example might then look like this:
Since the DNs are always evaluated in the format with forward slashes as field separators, an individual DN is always matched by the string "/". Using that as an access specifier is a convenient way to allow or deny access to all users.
Since the modification time of the .clarens_access file is used to determine whether it should be parsed, an ACL specification for a module or method in its own directory and the system directory will mean that the most recently modified ACL will be used.
File ACLs are analogous to the method ACLs discussed above, with the addition of fields for write access. The ACL file should also be called .clarens_access, and such a file may be placed in each directory.
For example if the below ACL specification is placed in the Clarens file service virtual root directory, everyone will be given read access to the "/" directory:
As with methods, an empty file or directory name indicates the current directory, while a named file of directory applies to its that entity in the current directory.
Extending this example to give wite access to the rootfiles subdirectory to people with DOEGrids certificates:
As the above example illustrates, it is possible to specify an ACL for a subdirectory (e.g. "rootfiles" above ) at a higher level in the directory hierarchy (e.g. "/" above). Since it is also possible to do so in the subdirectory itself, there may be two files specifying the ACL for that entity.
This should be avoided at all costs, since it is impossible to determine which ACL specification will actually be used. I.e. specify the ACL of an entity in only one .clarens_access file!