Skip to ContentSun and Oracle Channel Sun How to Buy Log In

Sun N1 Grid Engine 6.1 Installation Guide

查看這本書:

其他語言
日本語

包含在

Sun N1 Grid Engine 6.1 Collection

尋找其他文件

Appendix A Microsoft Services For UNIX

Overview

Microsoft Windows Services for UNIX (SFU) makes it possible to integrate some Windows operating systems into existing UNIX environments. It provides components that simplify network administration and user management across the UNIX and Windows platform.

SFU provides Interix a complete, high-performance UNIX environment that provides UNIX shells like csh or ksh, several hundred tools and utilities, and a complete set of development tools and libraries which make it possible to port and use your UNIX-based applications to the Interix subsystem.

Windows Services for UNIX provides:

In combination with Sun N1 Grid Engine the ability to integrate Windows hosts into N1GE clusters. This means that the execution and client environment of N1GE can be used on Microsoft Windows hosts.
Services and commands to access the network file system (NFS). This makes it possible to share files between the UNIX and Windows environment
A user mapping service which might access account and password services on UNIX and Windows systems (PCNFS, NIS)
"single sign-on" capability for the Windows and UNIX environment. Passwords can be synchronized and authentication credentials can be mapped between the UNIX and Windows operating systems.
The ability to execute UNIX shell scripts and applications to run on Windows-based computers in full-featured UNIX environments.

The following information describes the necessary steps to accomplish the installation of SFU. This document describes:

The unsupported N1GE functionality.
The SFU system requirements.
Information to consider before SFU installation.
The location of documentation which troubleshoots some common post installation and operation problems which might occur with SFU.

Unsupported N1GE Functionality

The following parts/applications which are part of a standard N1GE installation on UNIX operating systems are not supported in a Microsoft Windows environment and therefore cannot be used on Windows Hosts:

Master and Scheduler (sge_qmaster, sge_shadowd, sge_schedd)
Graphical User Interface (qmon)
DRMAA
qsh client command

System Requirements

The following requirements apply to the installation of Microsoft Services For UNIX.

The system must have Internet Explorer version 5.0 or later installed prior to running SFU setup.
The minimum hard disk requirements for installing SFU depends on which components you are installing. The maximum disk space requirement to install SFU components is 360 MB. The minimum disk space required is 20 MB. SFU must be installed on a partition that is formatted with the NTFS file system.
You cannot install SFU on a system running Microsoft Services for Network File System (for example, Microsoft Services for NFS is a component of Windows Storage Server 2003).
You must install the latest Windows service pack before installing SFU and N1GE then continue to install additional Windows service packs as they become available.
Data Execution Prevention (DEP) must be disabled. DEP is not compatible with some parts of SFU and might cause segmentation faults. See http://support.microsoft.com/kb/875352 for more informations about DEP. To disable DEP, follow these steps:
1. Right click on the "My computer" icon on the desktop.
2. Select "Properties".
3. In the Properties dialog box, select the "Advanced" tab and click the "Settings" button in the "Startup and Recovery" section.
4. In the next dialog box, click the edit button to edit the boot command line of your Windows installation.
5. Add "/noexecute=alwaysoff" or modify an existing "/noexecute" option.

You can find more details concerning SFU requirements at http://www.microsoft.com/windows/sfu/default.asp

Services for UNIX Installation

Microsoft's SFU is required to install N1GE successfully. You can download SFU from the http://www.microsoft.com. Search the site for “Windows Services for Unix” to find the current download information.

Get the SFU distribution media.

If you downloaded SFU, just execute the application to unzip the files into a directory. This directory must be located on a file system that has at least 480 MBytes free space.
Login to the Windows system with the Administrator account.
Start the setup.exe application which was unpacked previously.
Enter your name and organization.
Accept the license agreement for SFU.

Now you have to choose between the standard installation and custom installation. The standard installation is recommended.

If disk space is limited, you might also choose the custom installation path but make sure that at least following components will be installed:

Utilities -> Base Utilities

Interix Gnu components -> Interix GNU utilities

Remote connectivity components -> Telnet Server and Windows Remote Shell

If you intend to use NFS shared file systems then you also need: Authentication tools for NFS -> User Mapping and Server for NFS Authentication.

Depending on the underlying Windows operating system you might be asked two questions concerning the SFU security settings. The following screen shows the recommended selections:

The following information is a basic description concerning these two options. If you need further information please consult Microsoft's SFU documentation.

Enable suid behavior for Interix programs — According to the POSIX standard, a file has permissions that include bits to set both a UID (setuid) and a GID (setgid) when the file is executed. If either or both bits are set on a file, and a process executes that file, the process gains the UID or GID of the file. When used carefully, this mechanism allows a non-privileged user to execute programs that run with the higher privileges of the filers owner or group. When used incorrectly, however, this behavior can present security risks by allowing nonprivileged users to perform actions that should only be performed by an administrator. For this reason, Windows Services for UNIX Setup does not enable support for this mechanism by default.

You should enable support for setuid behavior because N1GE will be running programs that require this support. Even if you do not enable support for setuid behavior when installing Windows Services for UNIX, you can enable it later.

Changing Default Behavior to Case Sensitivity — You might be required to choose whether to change the default behavior of object names, such as file names, to being case sensitive. The choice you make will affect system security as well as how Windows Services for UNIX functions. With Microsoft Windows, the names of most objects (such as files and directories) are case preserving, but case insensitive. So, you cannot have two files in the same directory named sample.txt and Sample.txt because Windows regards the names as identical for the purposes of identifying files. However, the UNIX operating system is fully case sensitive. So, UNIX systems distinguish between object names when the only difference between those names is the case of the objectname characters. Therefore, sample.txt and Sample.txt could appear in the same directory and the UNIX system would distinguish between them when performing operations on the files. For example, the command rm S*.txt would delete Sample.txt but not sample.txt. In order to implement typical UNIX behavior, the Server for NFS and the Interix subsystem are normally case sensitive when working with file names.

This behavior can present security issues, particularly for users who are accustomed to the caseinsensitive conventions of Windows. For example, a Trojan horse version of edit.exe named EDIT.EXE could be stored in the same directory as the original. If a user were to type edit at a Windows command prompt, the Trojan horse version (EDIT.EXE) could be executed instead of the standard version. If case sensitivity is enabled, Windows users should be made aware of this possibility.

With Windows XP(Professional) and the Windows Server 2003 family, the default behavior of subsystems other than the Win32 subsystem is to be case preserving but case insensitive. In previous versions of Windows, such subsystems were fully case sensitive by default. In order to support standard UNIX behavior, Windows Services for UNIX Setup allows you to change the default Windows XP and Windows Server 2003 family behavior for non-Win32 subsystems when installing the base utilities (which installs the Interix subsystem) or Server for NFS. If you enable case sensitivity and then subsequently uninstall Server for NFS and the base utilities, Windows Services for UNIX Setup will restore the default, case-insensitive behavior of non-Win32 subsystems.
Configure User Name Mapping

User Name Mapping acts as a single clearinghouse that provides centralized user mapping services for the NFS client of Interix. User Name Mapping provides a map between the Windows users and groups on the NFS client, and the corresponding UNIX users and groups on the NFS server. In principle, these user and group names might not be identical, but for users who intend to use N1GE the names must be identical.

User Name Mapping lets you maintain a single mapping database for the entire enterprise. This feature makes it easy to configure authentication for multiple computers running Windows Services for UNIX. In addition to one-to-one mapping between Windows and UNIX user and group accounts, User Name Mapping permits one-to-many mapping letting you associate multiple Windows accounts with a single UNIX account. This feature can be useful, for example, when you do not need to maintain separate UNIX accounts for individuals and would rather use a few accounts to provide different classes of access permission. You can use simple maps, which map Windows and UNIX accounts with identical names. You can also create advanced maps to associate Windows and UNIX accounts with different names, which you can use in conjunction with simple maps.

For information about simple and advanced maps, see "Simple and advanced maps" in "Help for Services for UNIX"

Note –
Note: After the installation has finished, you can find "Help for Services for UNIX" here:

Start -> Programs -> Services for UNIX -> Help for Services for UNIX

User Name Mapping can obtain UNIX user, password, and group information from one or more Network Information Service (NIS) servers or from password and group files located on a local hard drive. The password and group files can be copied from a UNIX host or from a Windows-based system running Server for PCNFS.

Note –
User Mapping is part of SFU and not of N1GE. Please consult Microsoft Documentation and/or support to setup user mapping correctly.

Your selection in this dialog depends on the hosts and services which are currently provided in your Windows environment and also in the UNIX environment. Otherwise, if there is no such server in your environment then you should select Local User Name Mapping Server.

Note –
You should install SFU and enable the User Name Mapping service on your host which acts as Domain Controller for your windows environment. All other hosts should contact that Remote User Name Mapping Server.

If you choose Local User Name Mapping Server then you might either select Network Information Services (NIS) to access your passwd and group NIS-maps. Otherwise you have to select l if you will provide the files yourself.
Depending on your previous selections, you have either to enter the NIS Domain name and NIS Server name or the path of the passwd and group files.

Following, you will find an example for the files which have the standard UNIX format. This means that you can also use your /etc/passwd and /etc/group files from your UNIX environment.
```
 C:\Unix\etc\passwd
         
            root:x:0:0:UNIX root user:/home/root:/bin/tcsh
            user1:x:1002:100:Full name of user1:/home/user1:/bin/tcsh

         C:\Unix\etc\group

            root::0:
```
Note –
Some NIS maps do not contain an entry for user root. If this is the case and you intend to create following mapping, Administrator <-> root.

You create this entry by using the following steps:
1. First create a password file containing the root entry during this installation step.
2. If the SFU installation is finished then start the Services for UNIX Administration application and create the mapping: Administrator <-> root.
3. Switch to NIS mapping.
4. Use simple mapping or add manual mappings.
5. At this point the installation starts installing components. Wait until all components are installed.
When the installation process finishes, you may have to reboot the machine, depending on the version of Windows you are using.
Make sure that the Interix Subsystem Startup is started during boot time. If you intend to use NFS shares and user mapping then also start Client for NFS and User Name Mapping

Depending on the installation options and version of the Windows operating system, one or more of these services are disabled by default.

Post SFU Installation Tasks

There are several tasks you should do after you install the SFU software.

Before you start using SFU and before you actually install N1GE. please check that user mapping is working correctly by following these steps.
1. Open an Interix shell locally on the Interix host.
2. Use the login command to switch to a known user that is not the Administrator.
3. Verify the access permissions of NFS shares which should be accessible by that user.
4. Try to access these network resources. If a user cannot access a Network drive, most likely the User Name Mapping is not working correctly.
Check users home directories. To enable the automounting of the users home directories use this series of menus:
Control Panel -> Administrative Tools -> Computer Management -> Users -> Properties -> Profile
Click on connect to, select a drive letter, and enter the path of the users home directory in UNC notation:\\<server>\<share>\<user home>

Within the Interix subsystem, you might access all NFS shares through the special directory:/net/<server>/<share>

You might also create links to these directories to access the shares directly (for example, ln -s /net/myserver/export/share00/home /home).
Enable Administrator names on your machines.

Make sure that the Administrator accounts on all machines which should be enabled as executions hosts for N1GE use the same account name (e.g. Administrator).

Also make sure that this user has manager privileges in your N1GE cluster. If this is not the case then before the installation of the execution daemon, please add the privileges using this command:qconf -am <Administrator>
Set the CLI commands which start an editor. Make sure to set the EDITOR environment variable to vi or your preferred UNIX editor within the Interix subsystem before you start using UNIX commands.
Mount NFS shares.

There are two ways to mount NFS shares to the Interix host:
- The recommended way is using the auto mount functionality of Interix. All network shares that the Computer Browser service of Windows can find are automatically mounted to the "/net" directory of Interix. Some of them may be listed with "ls /net", some of the may be not, but the are anyway accessible. The syntax of the auto mounts is "/net/<server>/<share>", e.g. "/net/myserver/home". A link to a auto mounted share can be created to make it accessible under exactly the same name as on a Unix host. E.g. "ln -s /net/myserver/home /home" will make the users Unix home directories accessible via "/home/username". Automounted shares are available from boot time on, they are available for all users (who have, in general, the permissions to access these shares) and can't get lost by misconfiguration.
- Network shares can also be mapped to drive letters. This is done with the command "nfsmount". The syntax is "/usr/sbin/nfsmount -u: \\computername\sharename devicename" e.g. "/usr/sbin/nfsmount -u: \\\\myserver\\home Z:" (All backslashes have to be written two times, because the shell interprets a single backslash as an escape character.) This drive is now accessible via "/def/fs/Z". A link can be created to this drive to have the same path as on a Unix host.
Enable Interix inet daemons.

Although the Windows remote shell service and the Windows telnet service might be running on the host, you should disable the Windows daemons and use the Interix daemons instead. To disable the Windows services, go to "Control Panel"/"Services" and stop the services, set the start type to "disabled". To enable the Interix daemons, edit the /etc/inetd.conf file. It already contains lines for the daemons that are commented out. Remove the comment character (#) and save the file. Then run "/etc/init.d/inet start" to start the daemons. These daemons are necessary to make the N1GE commands qrsh and qlogin working.

If the user wants to do a passwordless rlogin to the host and wants to have access to network resources then, the user must register the password with the Interix command "regpwd". This is because the network component of Windows never trusts a passwordless login, with the registered passwords the rlogind can emulate a login with password."
Configure the users' home directories.

If the users' home directories are located on an NFS server, this must be configured in Windows. In the "profile" tab of the users properties dialog, select "Connect", a free drive letter and enter the path to the users home directory in the UNC notation \\server\share\directory, e.g. "\\myserver\home\Peter".

Troubleshooting SFU

The following section describes some common problems that users may encounter when installing and using N1GE in a Services for UNIX environment on a Windows system.

Impossible connect to the Interix subsystem via telnet or rsh

Make sure that the correct services are started. The corresponding Windows services have to be disabled. The Interix versions of telnetd and rshd have to be started. You can do this task by removing the pound sign (#) from the following lines part of /etc/inetd.conf
```
#telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd -i

   #shell stream tcp nowait NULL /usr/sbin/in.rshd in.rshd -a
```
If it is still not possible to connect to the machine, please check your firewall configuration. Donot block connections to corresponding ports:
```
Service  |  Ports
---------+-----------
ftp      |  20, 21
ssh      |  22
telnet   |  23
rsh      |  514
```
The wrong default login shell is started. Why?

.rhost and host.equiv authentications fails if new users accounts are created and if passwords of existing users are changed. The command regpwd has to be called. After that, use the steps to register passwords correctly.
Why is the access to NFS mounted home directories to slow?

User Name Mapping might be the cause for this problem. If you have a large number of user maps, installing User Name Mapping on a Domain Controller improves performance by reducing network traffic. It is possible to create a User Name Mapping server pool. This method means you can use DNS round-robin to create a pool of computers running User Name Mapping. This will provide improved performance on wide area networks as well as provide fail over when one of the servers is no longer available
How can I map user root if it does not exist in the NIS maps?

First create a passwd file which contains an entry for the user root. Then, explicitly map the root account (no basic mapping) using the created passwd file. Finally, change the mapping to use the NIS maps. Note that the previous root mapping will persist.
NIS Server cannot be contacted during the SFU installation

Interrupt the SFU installation and make sure that there is no other service or application running which already configures or uses the NIS server. If this is the case, then disable this service for the time of the SFU installation.
The Interix Subsystem of SFU and/or the User Mapping is not enabled after reboot

Make sure that following services are automatically started after machine reboot: Interix Subsystem Startup, User Name Mapping
Also if you use NFS mounted directories that also enable the service per default: Client for NFS
Queues stick in u-statefor a very long time

After the installation/restart of an execution host the corresponding queues have attached the unknown (u) state for a very long. This is normal behavior for Windows machines. After a full load report interval the u-state should be gone. If this is not the case, then check that the sge_execd has really been started on the corresponding machine.