User Management for Sun Grid Engine on Windows Hosts

<< Previous: Microsoft Services For UNIX

Next: Installing Sun Grid Engine >>

Searching Sun Grid Engine 6.2

Sun Grid Engine Information Center
Installing Sun Grid Engine
Index


User Management for Sun Grid Engine on Windows Hosts

Overview

Every user of the Grid Engine execution environment of a Windows machine must have a user account that has the same name as on the UNIX hosts. User accounts contain information about the user, including name, password, various optional entries that determine when and how users log on. and how their desktop settings are stored.

The following sections describe how you would use Windows user management to support Grid Engine.
Windows machines are referred to here using three different terms. The following table lists the terms and the operating systems which might run on each corresponding host:

Windows Host Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2000 Server, Microsoft Windows Server 2003
Windows Server Microsoft Windows 2000 Server, Microsoft Windows Server 2003
Windows Workstation Microsoft Windows 2000, Microsoft Windows XP

Managing Users on Windows Hosts

It is possible to administer user accounts on all Windows hosts individually. Each Windows Host has an authentication center which validates user names and corresponding user rights. User accounts which are defined on a Windows workstation are referred to here as local user accounts or local users.

Each Windows Host has its own local domain, and each Windows Server has the ability to make that domain available to other hosts. Account names within a local domain and account names within a server domain can collide. To avoid such collisions, you must specify the correct user account by providing the domain name as a prefix to the user account name followed by a + (plus sign) character.

Windows User Example

The following is an example that illustrates the potential complexity of Windows host accounts interacting with Windows Domain accounts. Suppose Windows Workstation host named CRUNCH has a local user account named Peter. This Windows Workstation is part of the domain named ENGINEERING. This domain is provided by a Windows Server which also has a user account named Peter. In this example, the ENGINEERING domain is the default domain of the host named CRUNCH. The following table shows the possible results of what would happen if a person tried to log in to CRUNCH.

Table – Using Domain Accounts
Login Name Result
CRUNCH+Peter Peter is logged in with his account as a local user of the machine CRUNCH.
ENGINEERING+Peter Peter is logged in with the account provided by the Windows Server hosting the ENGINEERING domain.
Peter This approach is equivalent to using ENGINEERING+Peter because CRUNCH has ENGINEERING as its default domain. Otherwise, the local account would be used.

Each domain has a special user account that provides superuser access. The default name for that account is Administrator. For native Windows, the members of the Administrators group and of the Domain Admins group in the server domain also have superuser access. However, for Interix, only the user Administrator of the local domain is the superuser of the local host.

The local Administrator can start applications in an account without knowing the password of the user for that account. However, the application would not be able to access network resources because even the local Administrator is not fully trusted by the network, unlike the Unix super user root. Therefore, the Sun Grid Engine administrator uses the sgepasswd tool to register the users' passwords, as explained in Using Grid Engine in a Microsoft Windows Environment.

UNIX User Management

UNIX has no equivalent to the Windows domain concept. With UNIX, each user has a local account and is authenticated as a local account even if the underlying account information lies on an LDAP or NIS server. The UNIX super user root is similar to the local Windows super user Administrator. The UNIX super user can start applications and processes on behalf of UNIX accounts without knowing each corresponding password.

Using Grid Engine in a Microsoft Windows Environment

The Grid Engine execution environment starts jobs on behalf of the submitting user. The execution daemon (sge_execd) on UNIX hosts runs as root so that it can start jobs on behalf of all users.

On Windows hosts, the execution daemon runs as the local Administrator user so that it can start jobs on behalf of users without knowing their password, but these jobs would not have the permissions to access network resources. Only fully authenticated users can access network resources. For a full authentication, the user's password is needed. Therefore, all users who want to submit jobs to a Windows execution host have to register their passwords with Grid Engine. The execution daemon still needs to run as the local Administrator to have the permissions to do several administrative tasks.

Registering Windows User Passwords

Users who want to start Grid Engine jobs on Windows execution hosts use the sgepasswd client application to register their Windows passwords. The following example shows Peter who has a user account in the domain ENGINEERING. Because ENGINEERING is the principal domain of the Windows execution host CRUNCH, Peter does not need to register his password for a specific domain. This should be the default in any properly set up single domain environment. In multiple domain environments, it might be necessary to register the password explicitly for a specific domain.

Note
You must run the sgepasswd command on a non-Windows host.
> sgepasswd
   Changing password for Peter
   New password:
   Re-enter new password:
   Password changed

Using the sgepasswd Command

The sgepasswd command changes the Grid Engine password file sgepasswd(5). This file contains a list of user names and their Windows passwords in encrypted form.

You can use sgepasswd to perform the following tasks:

  • To add a new entry for your user account.
  • To change your existing password, if you know your stored password.
    Caution
    If Grid Engine tries to run several of your jobs at once on a Windows execution host and is unable to access a correct password for your account, the Windows intrusion detection system could disable your account. To keep your account from being disabled, you must prevent your pending jobs from being run before you attempt to change your Windows user password. Once you have changed your password using sgepasswd on a non-Windows host and then on your Windows domain, you can allow your jobs to be run again.

Additionally, the root user can change or delete the password entries for other user accounts. sgepasswd is only available on non-Windows hosts.

The sgepasswd uses one of the following syntaxes:

sgepasswd [[ -D <domain> ] -d <user> ]

sgepasswd [ -D <domain> ] [ <user> ]

This command supports the following options:

-D domain By default, sgepasswd adds or modifies the current UNIX user name without a domain specification. You can use this switch to add a domain specification in front of the current user name. Consult your Microsoft Windows documentation for more information about domain users.
-d user Only root can use this parameter to delete entries from the sgepasswd(5) file.
-help Prints a listing of all options.

Additionally, the following environment variables affect the operation of this command.

SGE_CERTFILE Specifies the location of public key file. By default, sgepasswd uses the file $SGE_ROOT/$SGE_CELL/common/sgeCA/certs/cert.pem.
SGE_KEYFILE If set, this specifies the location of the private key file. The default file is /var/sgeCA/port$SGE_QMASTER_PORT/$SGE_CELL/private/key.pem.
SGE_RANDFILE If set, this specifies the location of the rand.seed file. The default file is /var/sgeCA/port$SGE_QMASTER_PORT/$SGE_CELL/private/rand.seed.

Adding Windows Hosts to Existing Grid Engine Systems

If you have a running Grid Engine system on which Windows support is not enabled, you can enable the support manually. The following steps provide a Windows-enabled Grid Engine system that allows additional Windows execution hosts.

How to Add Windows Hosts Later

  1. Copy Windows binaries to the $SGE_ROOT directory.

  2. Type the following command:
    qconf -mconf
    

    Set the execd_params to enable_windomacc=true.

  3. Type the following command:
    qconf -am <win_admin_name>
    


  4. Run the following command:
    $SGE_ROOT/util/sgeCA/sge_ca -init -days 365
    


  5. For a CSP installation, run the following command:
    $SGE_ROOT/util/sgeCA/sge_ca -user <win_admin_name>
    


  6. Type the following command:
    qconf -ah <new_win_hosts>
    


  7. Copy certificates to each Windows host.

  8. Set the owner of the certificates to ADMINUSER.
    Use a command similar to the following example:
    chown -R foo:bar /var/sgeCA/port <SGE_QMASTER_PORT>
    


  9. Run normal exec daemon installation on each execution host.

<< Previous: Microsoft Services For UNIX

Next: Installing Sun Grid Engine >>

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact