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 '/')
-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>
-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
-t <session timeout> in days
-v enable full verbosity
-w enable verbosity of warning messages
For example, to create a user with the following features
max cores per task: 8
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.
The tool does not save plaintext password, but rather it applies the cryptographic SHA-1 hash function and stores the resulting string into Ophidia DB and configuration file.
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
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.