[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]
Maui provides access control mechanisms to limit how the scheduling environment is managed. The primary means of accomplishing this is through limiting the users and hosts which are trusted and have access to privileged commands and data.
With regards to users, Maui breaks access into three distinct levels.
A level 1 Maui Admin has global access to information and unlimited control over scheduling operations. He is allowed to control scheduler configuration, policies, jobs, reservations, and all scheduling functions. He is also granted access to all available statistics and state information. Level 1 admins are specified using the ADMIN1 parameter.
Level 2 Maui Admins are specified using the ADMIN2 parameter. The users listed under this parameter are allowed to change all job attributes and are granted access to all informational Maui commands.
Level 3 administrators users a specified via the ADMIN3 parameter. They are allowed access to all informational Maui commands. They cannot change scheduler or job attributes.
If specified, the ADMINHOST parameter allows a site to specify a subset of trusted hosts. All administrative commands (level 1-3) will be rejected unless they are received from one of the hosts listed.
As part of the U.S Department of Energy SSS Initiative, Maui interface security is being enhanced to allow full encryption of data and GSI-like security.
If these mechanisms are not enabled, Maui also provides a shared secret key based security model. Under this model, each client request is packaged with the client ID, a timestamp, and a encrypted key of the entire request generated using a secret site selected key (checksum seed). A default key is selected when the Maui configure script is run and may be regenerated at any time by rerunning configure and rebuilding Maui.
|CSALGO||one of DES, HMAC, or MD5.||specifies the encryption algorithm to use when generating the message checksum.|
|CSKEY||STRING||specifies the shared secret key to be used to generate the message checksum.|
The CLIENTCFG parameter takes a string index indicating which peer service will use the specified attributes. In most cases, this string is simply the defined name of the peer service. However, for the special cases of resource and allocation managers, the peer name should be prepended with the prefix RM: or AM: respectively, as in CLIENTCFG[AM:bank] or CLIENTCFG[RM:devcluster].
E.2.2 Interface Development Notes
Details about the checksum generation algorithm can
be found in the Socket Protocol Description
[an error occurred while processing this directive] [an error occurred while processing this directive]