User Management¶

Command line tool¶

The command line tool oph_manage_user can be used to add a new Ophidia user, list users, remove them, etc. The prototype of this tool is

oph_manage_user -a add|del|list|update [-u <username>] [other options]

and its option are:

-a action to be executed:
        add: create a new user
        del: remove a user
        list: get user list
        update: change user parameters
-b to black-list a DN (GSI support only)
-c <maximum number of cores per task> (default 8)
-d <home data directory> (default '/')
-e <email>
-f <country>
-i <maximum number of hosts> (default 1)
-l option set in case a specific folder for user log data has to be created (valid only for type 'add')
-m <maximum number of opened sessions>
-n <name>
-o <OS username> that executes Ophidia operators (it is set to 'username' by default)
-p <password> or <VOMS role>
-r <yes|no> to enable|disable administration privileges
-s <surname>
-t <session timeout> in days
-u <username>
-v enable full verbosity
-w enable verbosity of warning messages

For example, to create a user with the following features

username: oph-new
password: s3cr3t
max cores per task: 8
name: New
surname: User
is_admin: yes

use the following command:

oph_manage_user -a add -u oph-new -p s3cr3t -c 8 -n New -s User -r yes

Only username and password are mandatory parameters in case of addition of a new user.

The tool can be used also to show user list (action list), to change user parameters (action update), to delete a user (action del), etc.

After user creation, configure user-specific parameters by editing /usr/local/ophidia/oph-server/authz/users/oph-new/user.dat.

GSI support¶

In case GSI support is enabled, users can be authorized to access Ophidia by means of the command line tool oph_manage_user too. The difference is the user identifier: for a GSI client refer to the Distinguished Name (DN) associated with the user certificate rather the username.

If you wish to add a new user manually, add the DN associated with the user certificate to the list of authorized DN in /usr/local/ophidia/oph-server/authz/dn.dat and set the appropriate access privilege. For instance, append a line as follows

/C=XX/O=XX/OU=Personal Certificate/L=XX/CN=XX:YYYY

where the sub-string ended with a colon (:) is the DN, whereas the last part YYYY is the user privilege.

Currently only two privileges are allowed:

• read: the user is authorized to access Ophidia, but it cannot create new sessions;
• write: the user is authorized to access Ophidia and it can create new sessions.

In case you wish to enable access to Virtual Organizations (VO) you shall append the VO name in /usr/local/ophidia/oph-server/authz/vo.dat. Create the text file vo.dat if it does not exist. VOMS parameters can be adapted according to the access policy you associate with each VO. Again only two privileges are defined:

• pdas_read: the user is authorized to access Ophidia, but it cannot create new sessions;
• pdas_write: the user is authorized to access Ophidia and it can create new sessions.

For example, if a member of VO named virtualorg wish to access Ophidia with the privilege pdas_write, it has to create the proxy certificate by submitting the following command:

voms-proxy-init --voms virtualorg:/virtualorg/oph/pdas/Role=pdas_write

provided that the configuration files used to connect to the VOMS server hosting virtualorg are correctly set.

Note that you can also configure a black list of DNs, which will be denied access to Ophidia, simply by reporting the list in /usr/local/ophidia/oph-server/authz/black_dn.dat (one DN per line). Create the text file black_dn.dat if it does not exist.