Overview of Services for UNIX 3.0 with Interix

Microsoft Windows Services for UNIX 3.0

On This Page

SFU Overview SFU Overview
SFU Lab Objectives SFU Lab Objectives
Lab 1: Services for UNIX (SFU) Installation Lab 1: Services for UNIX (SFU) Installation
Lab 2: Telnet Client and Server Lab 2: Telnet Client and Server
User Name Mapping User Name Mapping
Lab 3: User Name Mapping Lab 3: User Name Mapping
Understanding Client for NFS Understanding Client for NFS
Lab 4: Client for NFS Lab 4: Client for NFS
Understanding Server for NFS Understanding Server for NFS
Lab 5: Server for NFS Lab 5: Server for NFS
2-Way Windows/UNIX Password Synchronization 2-Way Windows/UNIX Password Synchronization
Lab 6: 2-Way Windows/UNIX Password Synchronization Lab 6: 2-Way Windows/UNIX Password Synchronization
Interix 2.2 Overview Interix 2.2 Overview
Interix 3 Lab Objectives Interix 3 Lab Objectives
Lab 9: Product Walk-through Lab 9: Product Walk-through
Interix 3Porting Interix 3Porting
Lab 10: Interix 3 Porting Examples Lab 10: Interix 3 Porting Examples

SFU Overview

  • Leverage Existing Network Resources

    • NFS Client, Server, and Gateway

    • PCNFS Server

  • Simplify Account Management

    • NIS Server and NIS Migration Wizard

    • User Name Mapping, Password Synch

  • Leverage Existing UNIX Knowledge

    • Full Interix Subsystem and Utilities

    • Over 350 Utilities and 1,900 UNIX APIs

  • Simplify Network Administration

    • Telnet Client and Telnet Server

    • Active State PERL, Microsoft Management Console

Microsoft Windows Services for UNIX (SFU) version 3.0 provides functionality to leverage UNIX resources, simplify network administration, and simplify account management in a mixed Windows and UNIX environment. In other words, SFU version 3.0 gives you the tools you need to integrate Windows into your UNIX network.

Objectives for Section 1

The objectives of this section are to provide an overview of the interoperability and management components in SFU 3.0, and how they achieve those goals by:

  • Leveraging Existing UNIX Network Resources.

  • Simplifying Account Management.

  • Leveraging Existing UNIX Knowledge.

  • Simplifying Network Administration.

In the following sections, we'll take a closer look at each of these important reasons for implementing SFU while we examine the features and functionality of SFU version 3.0.

Leverage Existing Network Resources

SFU gives you four important tools to allow you to leverage your existing UNIX network resources for your Windows-based clients and servers while also letting your UNIX clients utilize the resources of Windows-based servers. These tools are Client for NFS (Network File System), Server for NFS, Gateway for NFS, and Server for PCNFS**.**

Client for NFS

Client for NFS allows Windows-based computers to access files and directories that are stored on UNIX-based NFS file servers. It provides access to UNIX NFS shares similar to the way access to Windows file shares is provided natively on Windows. Access to NFS shares is provided with the help of another SFU component called the User Name Mapping service.

Server for NFS

Server for NFS is an NFS server implemented on a Windows-based server. It allows UNIX-based NFS clients to access files on Windows-based computers the same way files on other UNIX NFS servers may be accessed. For UNIX-based NFS users, this process is completely transparent. File-level access is determined by the user's User Identifier (UID) and/or Group Identifier (GID) and by Windows Access Control Lists (ACLs). Server for NFS supports NFS on all Windows-based file systems including FAT, CDFS, and NTFS.

Server for NFS allows UNIX and other NFS clients to access files stored on Windows-based file servers using NFS protocol. Server for NFS provides complete support for the NFS version 2 and 3 protocols. It supports NFS file locking specified by the Network Lock Manager (NLM) protocol.

Server for NFS integrates UNIX and Windows access control mechanisms in a natural manner. UNIX UIDs and GIDs from NFS requests are mapped to a corresponding Windows-based network user, and file access is provided in the context of the mapped user to ensure authenticated access. This ensures that users get file access that is consistent with their UID and privileges on a UNIX-based computer. It also ensures that unauthorized access is thwarted. A UNIX UID-to-Windows-based user name mapping is provided using a SFU component called User Name Mapping. On the other hand, authentication of NFS requests is provided by a SFU component called Server for NFS Authentication. Access may be provided to both local users and domain users.

Gateway for NFS

Gateway for NFS allows access to NFS shares for computers without NFS client software installed on them. This is useful for Windows operating systems-based computers without Client for NFS installed on them. Gateway for NFS acts as a gateway between the Windows-based network and the UNIX-based network. Gateway for NFS mounts NFS shares and exports them as Windows shares. Windows-based computers access NFS shares using Windows-based networking via the share exported by the Gateway for NFS.

Gateway for NFS also uses the User Name Mapping service to map Windows-based credentials to UNIX UIDs or GIDs before forwarding the file access requests to NFS servers. Each gateway request from a separate user is properly identified and Windows user names are mapped to corresponding UNIX users before being forwarded to the NFS server.

Server for PCNFS

Server for PCNFS enables Windows 2000 to act as a PCNFS daemon (PCNFSD) server, to provide seamless user authentication services when connecting to NFS servers.

Simplify Account Management

SFU version 3 provides important tools to help simplify the account management in a mixed Windows and UNIX network.

Server for NIS (Network Information Service)

Server for NIS, which provides NIS server functionality based on Windows 2000 Active Directory. Server for NIS installed on a Windows 2000 Server domain controller can be used as a master NIS server to administer a UNIX NIS domain. Server for NIS implements NIS 2.0 protocol. It supports both UNIX-based NIS subordinate (slave) servers as well UNIX-based NIS clients.

Server for NIS stores NIS objects in Active Directory, and it integrates UNIX users, groups, and hosts into their Windows-based equivalents. With this feature, UNIX users and groups can be administered the same way Windows users and groups are administered. NIS data can be managed using Active Directory tools (e.g. User and Computer snap-in). Further, any users who are common to both UNIX and Windows networks can be represented uniquely in the Active Directory. This creates a common name space, reducing the administrative overhead of managing two separate names spaces and directories.

Migration of NIS domains to Server for NIS

Server for NIS allows administrators to migrate NIS domains and maps, and merge them with existing NIS domains. This allows an existing NIS server running on UNIX to be migrated to Window 2000-based computers.

User Name Mapping

The User Name Mapping Server is a component of SFU that allows mapping Windows user names to UNIX user names and vice versa. This is a means to associate user names or identifications in Windows and UNIX-based domains. The NFS components use User Name Mapping for bridging the gap between Windows authentication and the UNIX UID or GID that is part of NFS requests. It maps an authenticated Windows user's credentials to a UID/GID. With this feature, Client for NFS or Gateway for NFS allows Windows users access to NFS resources without explicit UNIX authentication. Server for NFS uses this mapping to provide access privileges to NFS requests originating from UNIX-based computers containing only UNIX identification1.

User Naming Mapping can be used as a central server in the enterprise network. This simplifies the task of administration since mappings need to be maintained only on one server. If all Windows-based NFS components use the central user name mapping, users get consistent access to NFS resources from anywhere in the network.

Password Synch

Password Synchronization allows Windows-to-UNIX password synchronization and vice versa. Password Synchronization can synchronize passwords for local passwords as well as domain passwords. For domain passwords, Password Synchronization must be installed on Windows NT or Windows 2000-based domain controllers. Password change requests from Windows to UNIX and UNIX to Windows are encrypted using strong encryption (Triple-DES algorithm).

Password change requests are sent to only to those computers selected by administrators. The list of hosts is specified in a configuration file for UNIX-to-Windows synchronization, whereas they are specified using administration tools for Windows-to-UNIX synchronization. Administrators can also specify users for whom passwords should be synchronized or for whom passwords should not be synchronized.

Leverage Existing UNIX Knowledge

SFU includes the Interix subsystem technology with both Korn and C shells, over 350 UNIX utilities and an SDK that supports over 1,900 UNIX APIs, giving programmers and system administrators the tools to easily migrate applications and scripts to Windows. Additionally, the GNU SDK and key GNU compilers and utilities are provided. All running natively on SFU.

Interix is useful to create scripts to do many repetitive administrative tasks. These include monitoring processes or viewing disk usage and available space. Utilities that allow administrators to do repetitive tasks include, ps, kill, and top for process management, and du and df for disk space monitoring.

Programmers can migrate existing UNIX applications to Interix easily and with few, if any, changes. Interix supports a single rooted file system, symbolic and hard links, and is fully case sensitive.

Simplify Network Administration

SFU provides tools to enhance and simplify the administration of your network.

Telnet Client

With Telnet client for Windows, Windows users can connect to a remote UNIX- or Windows-based computer and execute programs remotely. Telnet client supports a variety of terminal emulators including VT100, ANSI, and VTNT. It also supports NTLM authentication.

Telnet client provides features to log the entire Telnet session to a file. It also supports a variety of options that are applicable to connecting to telnet servers.

Telnet Server

With telnet server for Windows, UNIX users can connect to Windows computers for executing programs or administering the computer. This allows administrators to administer Windows computers without leaving their desktop.

Telnet server supports a new terminal type called VTNT that supports access to the complete functionality of the Windows command console. Telnet server also supports the NTLM authentication scheme, which allows SFU and other telnet clients that support NTLM to connect without sending a password over the network. Telnet server supports two modes of operations:

  • Console mode. This mode is useful to run screen-oriented programs such as vi.

  • Stream mode. This mode operates similar to UNIX dumb terminal type but is not suitable to use with programs such as vi.

Telnet server logs a variety of telnet-related activities, such as auditing, monitoring telnet sessions, and sending messages to telnet connections. Telnet server allows the user to keep applications running even after disconnecting.

ActiveState PERL

ActiveState PERL provides the ability to automate network administrative tasks by running new or existing Perl scripts natively on Windows NT or Windows 2000.

Microsoft Management Console

Microsoft Management Console (MMC) enables administrators to centralize all Windows SFU 3.0 management from a single application, as well as from the command line.

References:

For more details about SFU, refer to the following links:

https://www.microsoft.com/windows/sfu

SFU Lab Objectives

  • Product Installation

  • Product Walk-Through

  • SFU Administrative Examples and Problems

Lab 1: Services for UNIX (SFU) Installation

3ovw19

Lab Tasks

In this lab, you will perform the following tasks:

  • Install SFU

  • Use of the SFU Administration Console to configure and manage SFU components

Exercise 1-1: Install SFU

Overview

To Install Windows SFU from Windows:

  1. Insert the Windows SFU compact disc into the CD-ROM drive.

  2. In the Windows Services for UNIX Wizard dialog box, click Next.

  3. In the User name box, type your name. If the name of your organization does not appear in the Organization box, type the name of your organization there.

  4. In the CD Key box, type the product key found on the back of the CD-ROM case, and then click Next.

  5. Read the Microsoft Software License Terms carefully. If you accept the terms of the agreement, click I accept the terms in the License Agreement, and then click Next to continue installation.

    Note: If you click I do not accept the License Agreement (Exit Setup), the installation procedure will terminate.

  6. To complete installation of default Windows SFU components in the default directory, click Standard installation. If you want to specify a different set of components or a different installation location, click Customized installation.

    Note: This lab requires that you select the Standard installation option.

  7. Adjust the settings in the Security Settings dialog for your environment, and then click Next.

  8. If you are customizing your installation, click the icon next to each component that you want to install and click the appropriate option. If you do not want to install a component, click the icon next to the component and click Entire feature will not be available.

    3ovw05

  9. Select the following components for use in this lab:

    • Telnet Server (under Remote Connectivity)

    • Base Utilities (under Utilities)

    • Interix GNU Utilities (under Interix GNU Components)

    • UNIX/Windows Password Synchronization

    • Client for NFS and Server for NFS (under NFS)

    • User Name Mapping (under Authentication tools for NFS)

    • Server for NFS Authentication (under Authentication tools for NFS)

    Other available components (not to be selected for this Lab) are as follows:

    • Remote Shell Service (under Remote Connectivity)

    • GNU SDK (under Interix GNU Compents)

    • Interix SDK

    • UNIX Perl (under Utilities)

    • ActiveState Perl

    • Server for NIS (Windows 2000 Domain Controller only)

    • Gateway for NFS (under NFS, Windows Server only)

    • Server for PCNFS (under Authentication tools for NFS)

  10. When you are finished specifying the components to install, click Next.

  11. In the Installation location box, type the fully qualified path of the directory where you want to install Windows SFU, and then click Next to complete installation.

Notes:

  • If you are installing Client/Server for NFS, you will be prompted for the name of your organization's User Name Mapping server. If you do not know the name of the User Name Mapping server, click Next; you can specify the name of the server later using Windows SFU Administration. If you are also installing User Name Mapping, type the name of the server on which you are installing Windows SFU.

  • You can install additional components or remove installed components at any point of time.

  • Windows SFU components cannot be run from a network server. All files must be installed on the local computer.

Exercise 1-2: Use SFU Administration

Overview

To Use Windows SFU Administration:

  1. Click on Start/Programs/Windows Services for UNIX, and select Services for UNIX Administration. The SFU Administration window appears.

    3ovw07

  2. Click on components to view their associated configuration options.

    For example, click Telnet Server to view its configuration:

    3ovw08

Notes:

  • SFU Administration is the utility to graphically configure, start, or stop various components.

  • Users can also use the command line to manage the components.

    For example, to start Server for NFS, type:

nfsadmin server [\ComputerName] start

at the command prompt.

However, in this lab, we will primarily use SFU Administration to configure and manage all SFU components.

References (SFU Training Material and Whitepapers)

For more details about SFU Installation and Features, refer to:

https://www.microsoft.com/windows/sfu

Lab 2: Telnet Client and Server

Lab Tasks

In this lab, you will perform the following tasks:

  • Connect to a Remote UNIX Machine using a Telnet Client

  • Configure a Telnet Server

  • Share Windows Files using Telnet Server

Exercise 2-1: Connect to a Remote Machine using a Telnet Client

  • Telnet Client quick review

  • Using Telnet Client

  • Commands

    • Sessions mode and command mode

    • Window resizing

    • Scrolling support

Telnet Client quick review

  • Telnet uses the Telnet protocol (part of the TCP/IP protocol suite) to connect to a remote computer over a network. Telnet Client software allows a computer to connect to a remote Telnet server and run applications on that server.

  • Windows SFU includes an improved, command line-oriented Telnet client. You can use the NTLM protocol to authenticate clients for Telnet connections between computers running Windows 2000 or Windows XP.

To Connect to a Remote Machine:

  1. Click Start, point to Programs, point to Windows Services for UNIX, and then click Telnet Client.

  2. Enable the Telnet logging option. At the Telnet prompt, type

    set logfile filename

    Where filename is the file to be used for logging Telnet activity. The log file must be on your local computer. Logging begins automatically when you set this option. For this activity, specify the filename as C:\telnet.txt.

    Note: This activity must be performed for each session for which you desire Telnet activity logging.

  3. At the Telnet prompt, type:

    open lnxdell

    Where lnxdell is the name of remote machine running Telnet Server.

  4. To logon to Telnet server computer, type:

    login: user1 Password: user1

  5. To see the directory listing, including directory entries whose names begin with a dot (.) and in the "long" format, type:

    ls -al

  6. To disconnect from the remote machine, type:

    exit

  7. To stop the Telnet Client, type:

    Quit

  8. List contents of C:\telnet.txt file (for example, type C:\telnet.txt at a command prompt).

    The result should resemble the following:

Red Hat Linux release 6.1 (Cartman) Kernel 2.2.12-20 on an i686 login: user1 Password: Last login: Wed Apr 18 05:42:50 from w2ksgw [user1@lnxdell user1]$ ls -al total 32 drwx------ 2 user2 users 4096 Oct 18 2000 . drwxr-xr-x 8 root root 4096 Oct 18 2000 .. -rw-r--r-- 1 user2 users 1422 Oct 18 2000 .Xdefaults -rw------- 1 user2 users 92 Apr 18 05:44 .bash_history -rw-r--r-- 1 user2 users 24 Oct 18 2000 .bash_logout -rw-r--r-- 1 user2 users 230 Oct 18 2000 .bash_profile -rw-r--r-- 1 user2 users 124 Oct 18 2000 .bashrc -rw-r--r-- 1 user2 users 3394 Oct 18 2000 .screenrc [user1@lnxdell user1]$ exit logout

Exercise 2-2: Configure a Telnet Server

  • Telnet Server quick review

  • Configure Telnet Server Settings

Telnet Server quick review

  • Telnet Server is a gateway for Telnet clients. When Microsoft Telnet Server is running on a computer, users can use Telnet clients to connect to it from remote computers. When a Telnet client connects to the Telnet server, the remote user is asked to enter a user name and password. By default, only user name and password combinations that are valid on the local server can be used to log on to that server.

  • Once logged on, a user is given a command prompt that can be used as if it had been opened in a command prompt window locally. By default, however, the user cannot use applications that interact with Graphical User Interface (GUI).

  • Telnet uses the Telnet protocol (part of the TCP/IP protocol suite) to connect to a remote computer over the network.

To Configure Telnet Server Settings:

  1. Open Windows Services for UNIX Administration.

  2. Click Telnet Server.

  3. To set authentication methods, click the Authentication tab, and select both NTLM and Plaintext checkboxes..

  4. Set Server Settings by doing the following:

    1. Click the Server Settings tab.

    2. In the Maximum number of simultaneous connections list, click a value to specify the number of simultaneous connections to the server that will be allowed.

    3. In the Maximum number of failed login attempts box, type the number of failed logon attempts a user will be allowed.

    4. In Telnet port, type the number of the port Telnet Server will monitor for connection requests.

    5. In Mode of operation select Console or Stream from the drop down list.

    6. In Default Domain Name, type or select the name of the domain you want to set as the default. A user who is a member of the default domain does not have to enter the domain name as part of the logon name.

    7. Click Disconnect idle client sessions after, and then, in the boxes provided, type a value in hours, minutes, or seconds.

    8. Click Interpret CTRL+A as ALT if you want to be able to pass the ALT key to the server.

    9. Click Stop all programs to have programs (associated with the telnet session) terminate when the user ends the Telnet session. Note**:** For this exercise use all the defaults

    10. To save the settings, click Apply.

  5. For the settings to take effect, stop and restart the server.

User Name Mapping

  • Understanding User Name Mapping

    • Allow Windows users access NFS servers using Windows credentials

    • Allow Unix users access NFS files on Windows servers

    • Keep consistency in file access across all NFS clients and servers

    • Ease administrative task maintaining mappings on all machines

  • Simple and Advanced Maps

Understanding User Name Mapping

  • User Name Mapping acts as a single clearinghouse that provides centralized mapping services for Client for NFS, Gateway for NFS, and Server for NFS.

  • User Name Mapping lets you create maps between Windows and UNIX user and group accounts even though the user and group names in both environments may not be identical. Perhaps most important, User Name Mapping lets you maintain a single mapping database for the entire enterprise. This makes it easy to configure authentication for multiple computers running Client for NFS, Gateway for NFS, and Server for NFS.

  • In addition to one-to-one mapping between Windows and UNIX user and group accounts, User Name Mapping permits one-to-many mapping. This lets you associate multiple UNIX accounts with a single Windows account, or multiple Windows accounts with a single UNIX account. This 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.

  • User Name Mapping can obtain UNIX user, password, and group information from one or more NIS servers or from password and group files. The password and group files can be on a UNIX computer running the PCNFS daemon (PCNFSD), a Windows computer running Server for PCNFS, or stored locally (e.g. transferred from the Unix Server via FTP) on the Windows User Name Mapping computer.

  • User Name Mapping periodically refreshes its mapping database from the source databases, ensuring that it is always kept up to date as changes occur in Windows and UNIX name spaces. You can also refresh the database anytime you know the source databases have changed.

  • You can back up and restore User Name Mapping data at any time. Because the database is backed up to a file, you can use that file to copy the mapping database to another server. This provides a level of redundancy for fault tolerance.

  • If you obtain information from multiple NIS domains, it is assumed that each domain will have unique User Identifiers (UIDs).

User Name Mapping (Server)

3ovw13

  1. NFS client includes the UID/GID in the mount request to the Server for NFS for the requested NFS file share.

  2. Server for NFS maps UID/GID to a corresponding Windows-based user name using mapping data provided by the User Name Mapping server.

  3. User Name Mapping Server returns the SID credentials of the mapped Windows users.

  4. The File share is now accessible from the Unix client, with authorization based on the credentials (SID) of the impersonated Windows user from Name Mapping (Step 3).

  5. NFS request is fulfilled to the NFS client

User Name Mapping (Client)

3ovw14

  1. The Windows credentials (SID) are sent to the User Name Mapping Server, which maps the Windows user's credentials to the Unix user and group names

  2. The User ID (UID) and Group ID (GID) are returned to the Windows NFS client.

  3. Client for NFS stores the returned UID/GID (for subsequent access to the same UNIX NFS server) and includes the UID/GID in the mount request to the UNIX server for the NFS file share.

  4. File share is now accessible from the Windows client, with authorization based on the UID/GID sent in the mount request.

Simple and Advanced Maps

  • Simple Maps : In a simple user map, users in a Windows domain are implicitly mapped one-to-one to UNIX users on the basis of user name. When the Windows domain and the UNIX passwd and group files or Network Information Services (NIS) domain are identified, User Name Mapping maps users and groups that have the same name in both the Windows and UNIX or NIS domain. If there is no match for a user/group name in either place, that user/group is not mapped to anything.

  • Advanced Map : You can use advanced maps to set up one-to-one, one-to-many, or many-to-one mappings between Windows users and UNIX users and groups. For example, a Windows user name could be mapped to several UNIX user names, or a UNIX group could be mapped to a Windows user. Advanced maps can also be used when the same person has different user names on Windows and UNIX.

Once maps are set up, users can log on to Windows using their Windows user name/password, and access UNIX resources without supplying a UNIX user name and password. User Name Mapping checks the authenticity of the Windows user and issues the appropriate UID/GID for use with the UNIX system. Likewise, UNIX users can log on to their computers and access Windows files (User Name Mapping provides the credentials). If the same user appears in both a simple and an advanced map, the advanced map is used.

Lab 3: User Name Mapping

Lab Tasks

In this lab you will perform the following tasks:

  • Configure the User Name Mapping service

  • Create a simple user map

  • Create an advanced user map

  • Start/Stop the User Name Mapping service

Exercise 3-1: Configure the User Name Mapping Service

To specify the type and names of servers that will provide UNIX user names and credentials:

  1. Start Services for UNIX Administration.

  2. Click User Name Mapping, then click Configuration tab.

  3. Click Personal Computer Network File System (PCNFS).

  4. In the Password file path and name box, type C:\SFU\etc\passwd

  5. In the Group file path and name box, type C:\SFU\etc\group

  6. To specify the refresh interval, type a new refresh interval in the Hours and Minutes boxes.

    Note: You can also use the default refresh interval provided.

  7. To save the settings, click Apply.

Exercise 3-2: Create a Simple User Map

If the user and group names are identical on Windows and UNIX, and if you want to map identical names directly to each other, you can create simple maps.

To create a simple user map:

  1. Start Services for UNIX Administration.

  2. Click User Name Mapping.

  3. Click the Maps tab, and then select Simple maps.

  4. Verify the Windows Domain Name in the configuration box.

  5. To save the settings, click Apply.

Exercise 3-3: Create an Advanced User Map

If the Windows and UNIX names are not identical, or if you want to map one name to several other names, create advanced maps.

To create an advanced user map:

  1. Start Services for UNIX Administration.

  2. Click User Name Mapping.

  3. Click the Maps tab, and then click Show Group Maps.

  4. In the Windows domain name list, click the domain for which you want to list users. For this lab, select the correct domain, and then click List Windows Groups.

    Note: If you were obtaining UNIX user information from an NIS server, in the NIS Domain name box, you would type the name of the NIS domain from which you are getting account information.

  5. To view the list of UNIX groups, click List UNIX Groups.

  6. Select Domain Users from the Windows group name: and users from the UNIX group name: list boxes, and click on the Add button.

  7. When you map multiple users to one user, you follow the instructions to set the primary mappings.

  8. To save the settings, click Apply.

Exercise 3-4: Start/Stop the User Mapping Service

To start or stop the User Mapping Service:

  1. Start Services for UNIX Administration.

  2. To start the mapping, right-click User Name Mapping, and then click Start.

  3. To stop the mapping, right-click User Name Mapping, and then click Stop.

Understanding Client for NFS

  • Seamless access to NFS servers

    • Access NFS servers using Windows credentials

    • Maps Windows name to UNIX UID using User Name Mapping Service

  • Integration of NFS with Windows UI

    • Browsing NFS network, servers and shares
  • Windows semantics

    • Case sensitivity, 8.3 naming, share locks, access to NFS via DFS, UNC naming, 'net' commands
  • Client for NFS gives a Windows-based computer the ability to act as a client to an NFS server. With Client for NFS, you can access files in a mixed environment of computers, operating systems, and networks.

  • Once Client for NFS is installed and configured, you can connect to and disconnect from an NFS share. You can access files on the NFS server by mounting those files to your computer using either the UNIX server:/export format or the Windows \\server\share format. You can also mount exported (i.e. shared) folders by browsing the NFS LANs in the NFS Network folder located in Network Neighborhood (on Windows NT) or My Network Places (on Windows 2000). Files mounted on the NFS server are treated as though they reside on the client computer and are indistinguishable from files on the client computer.

  • All applications running on the Windows-based computer can use Client for NFS to access files on remote computers.

Lab 4: Client for NFS

Lab Tasks

In this lab you will perform the following tasks:

  • Configure Client for NFS

  • Start/Stop Client for NFS

  • Map a Network Drive to NFS

  • Browse the NFS Network

  • View NFS Network, File Settings

  • Disconnect a Network Drive

Exercise 4-1: Configure Client for NFS

  1. Start Services for UNIX Administration.

  2. Click the Settings tab of Services for UNIX[local], type W2KSGW or the correct User Name Mapping Server as the name of the mapping server.

  3. Click Client for NFS.

  4. Click the File Permissions tab. Under File Access, note the defaults permissions.

  5. Click the Performance tab, accept the default values for the performance parameters.

  6. Click Apply to save the settings.

Exercise 4-2: Start/Stop Client for NFS

  1. Open Services for UNIX Administration.

  2. To stop Client for NFS, right-click Client for NFS, and then click Stop.

  3. To start Client for NFS, right-click Client for NFS, and then click Start.

Stopping and Starting the Client for NFS service is required to "activate" the changes made in exercise 4-1.

Exercise 4-3: Map a Network Drive to NFS

  1. Log off as Administrator and log on as user2 with password user2.

  2. Open Windows Explorer.

  3. On the Tools menu, click Map Network Drive.

  4. In the Drive list, click the drive letter that is to be used.

  5. To locate the NFS share, click Browse, or, in Folder, type the path to the share. You can specify the path as:

    serverName :/ path -- for the lab example: lnxdell:/home/user2

    or as:

    \\ serverName \ path --- for the lab example: \\lnxdell\home\user2

  6. You'll see a dialog with the resultant credentials displayed.

  7. Click the Yes button.

Notes:

  • If you type the path to the share, the first format shown above is preferred. It causes lookup operations to timeout more quickly, and therefore locates/mounts the NFS resource sooner. The second format searches for Windows file shares (i.e. SMB file shares) with this name first, and then searches for NFS resources.

  • To connect using a different user name or password, click Connect using a different user name, type the user name and password, and then click OK.

Exercise 4-4: Browse the NFS Network

  1. Double-click My Network Places or Network Neighborhood, and then double-click Entire Network.

  2. Double-click NFS Network.

  3. Double-click the local area network (LAN) whose servers you want to view, in this case Default LAN.

  4. Double-click the server whose shared directories you want to view, in this case lnxdell.gwtwork.com.

  5. Double-click the shared directory containing the directory or file you want to open, in this case \home.

  6. Double-click the directory or file you want to open, in this case user2.

Exercise 4-5: View NFS Network and File Settings

To View the Properties of a File or Directory:

  1. Right-click the name of the file or directory and then click Properties.

  2. Click the NFS Attributes tab. The properties for the user2 directory are displayed.

    3ovw16

To View NFS Server Properties:

  1. Right-click the name of the server whose properties you want to view (in our case lnxdell.gwtwork.com), and click Properties.

  2. When you click a directory in the Exported File Systems list, the computers that have access to it appear in the Access List (see following snapshot):

    3ovw17

To view NFS Mount Options:

  1. Right-click the drive assigned to an NFS mount, and then click Properties.

  2. To view the NFS mount options for the file or directory, click NFS Mount Options tab.

    3ovw18

Exercise 4-6: Disconnect a Network Drive

  1. Open Windows Explorer.

  2. Right-click the drive that is mapped to a remote network drive, and then click Disconnect.

Understanding Server for NFS

  • Allow UNIX clients to access files on Windows servers

  • File access using UNIX UID/GID

    • Map UID to a domain user(s) with User Name Mapping Service

    • File access privileges according to mapped user

  • NFS access with just UNIX sign-on

  • NFS semantics

    • Support v2/v3, TCP/UDP, locking
  • With Server for NFS, a computer running a Microsoft Windows NT or Windows 2000 operating system can act as a Network File System (NFS) server. Users can then share files in a mixed environment of computers, operating systems, and networks.

  • Users on computers running NFS client software can gain access to files (called shares) on the NFS server by connecting (mounting) those files to their computers. From the viewpoint of the user on a client computer, the mounted files are indistinguishable from local files.

  • Server for NFS uses the Open Network Computing remote procedure call (ONC RPC) protocol to implement the NFS protocol. Server for NFS also uses the external data representation (XDR) protocol to ensure portable data transmission between NFS clients and the NFS server.

  • UNIX computers follow advisory locking for all lock requests. This means that the operating system does not enforce lock semantics on a file, and applications that check for the existence of locks can use these locks effectively. However, Server for NFS implements mandatory locks even for those locking requests that are received through NFS. This ensures that locks acquired through NFS are visible through the server message block (SMB) protocol and to applications accessing the files locally. Mandatory locks are enforced by the operating system.

Lab 5: Server for NFS

Lab Tasks

In this lab you will perform the following tasks:

  • Configure Server for NFS

  • Start/Stop Server for NFS

  • Start Sharing a Directory, and Add Client Groups to NFS Share

  • Stop Sharing a Directory

  • Share Windows Files using Server for NFS

Exercise 5-1: Configure Server for NFS

  1. Start Services for UNIX Administration.

  2. Click the Settings tab of Services for UNIX[local], type W2KSGW or the correct User Name Mapping Server as the name of the mapping server.

  3. Click Server for NFS.

  4. Click the Logging tab. Configure the following options:

    1. Select Log events in this file. Specify the name and path of the default log file as C:\SFU\log\nfssvr.log in the text box. You can also click Browse and find the file.

    2. In Maximum file size, you can modify the maximum size for the log file.

    3. In Event types, select the events to log. For the purposes of this lab exercise, select the All option. The All option will select the following:

      • Mount. Users making mount and unmount requests.

      • Locking. Users locking and unlocking files.

      • Read. Users making requests to read a file.

      • Write. Users making requests to write to a file.

      • Create. Users making requests to create a file.

      • Delete. Users making requests to delete a file.

      • All. All of the above – this is what we will use for this exercise

  5. Click the Locking tab. In Waiting period, type the number of seconds users have to re-establish locks after the server restarts. For this lab exercise, specify the waiting period as100.

  6. Click the Client Groups tab.

  7. In the Group Name text box, type the name of the group you are creating:. For this lab exercise, select UnixGroup, and then click New.

    Note: The group name should not be the same as the name of any host in the NFS network.

  8. Click Advanced and then in the text box, type the name of the client you are adding to the UnixGroup, which is lnxdell, and then click Add Clients button.

  9. Click Apply to save the settings.

Exercise 5-2: Start/Stop Server for NFS

  1. Open Services for UNIX Administration

  2. To stop Server for NFS, right-click Server for NFS, and then click Stop.

  3. To start Server for NFS, right-click Server for NFS, and then click Start.

Stopping and Starting the Server for NFS service is required to "activate" the changes made in exercise 5-1.

Exercise 5-3: Start Sharing a Directory, and Add Client Groups to NFS Share Permissions List

  1. Open Windows Explorer.

  2. In the details pane, right-click the directory that you want to share: C:\NFSDir

  3. Click Sharing.

  4. Click the NFS Sharing tab.

  5. Click Share this folder. Notice that the default share name is specified as NFSDir. Accept the default for this lab exercise.

  6. Click Permissions, click Add, and then do one of the following:

    1. In the Names list, click the UnixGroup group to add fro this exercise. Note: To see a list of the members of a group, in the Names list, click a group, click Members, and then click the names of members you want to add to the permissions list.

    2. Click the Add button, and then click the Type of Access drop down list and pick root.

    3. Click the OK button in the Add Clients and Client Groups dialog box, and then click the OK button in the NFS Share Permissions dialog box.

  7. To confirm the specified settings, click OK.

Exercise 5-4: Stop Sharing a Directory

  1. Open Windows Explorer.

  2. In the details pane, right-click the directory you want to stop sharing.

  3. Click Sharing in the pop-up menu.

  4. The Property dialog box is displayed. Click NFS Sharing.

  5. To stop the sharing, click Do not share this folder.

  6. Click OK or Apply.

Exercise 5-5: Share Windows Files using Server for NFS

  1. Start a Telnet session.

  2. To connect to a UNIX machine, type openlnxdell at command prompt.

  3. Logon to Telnet server computer as follows:

    login: root Password: root

  4. Once logged onto the UNIX machine, to mount the Windows NFS file system share, specified as NFSDir, to the UNIX NFS clients directory tree at /mnt, type the following command at the prompt:

    mount w2ksgw:/NFSDir /mnt

  5. Logoff Telnet server computer.

  6. Logon to Telnet server computer as follows

    login: user2 Password: user2

  7. To change the working directory to /mnt; create a new directory called user2; and list the contents of the working directory (/mnt), type the following commands at the prompt:

cd /mnt mkdir user2 ls –al

The output of the ls –al command should resemble the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

[user2@lnxdell /mnt]$ ls –al total 5 drwxrwxrwx 2 root 65535 64 Apr 18 2001 . drwxr-xr-x 19 root root 4096 Oct 16 2000 .. drwxr-xr-x 2 user2 users 64 Apr 18 2001 user2 [user2@lnxdell /mnt]$

Notice that **user2** is the owner of the directory user2 and that the **users** group is the primary group for directory user2.
  1. Type the following commands at the prompt:

cd user2 touch test.txt ls –al

The output of the ls –al command should resemble the following:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

[user2@lnxdell user2]$ ls -al total 1 drwxr-xr-x 2 user2 users 64 Apr 18 2001 . drwxrwxrwx 2 root 65535 64 Apr 18 2001 .. -rw-r--r-- 1 user2 users 0 Apr 18 2001 test.txt [user2@lnxdell user2]$

2-Way Windows/UNIX Password Synchronization

  • Ability to change password from Windows or UNIX (two-way)

  • Encrypted propagation based on Triple-DES

  • Ability to send to targeted computes

  • Ability to filter based on user names when sending and receiving

  • Limited to users with identical names

Understanding Password Synchronization

  • Password Synchronization helps integrate Windows and UNIX networks by simplifying the process of maintaining secure passwords in both environments. Users are freed of the difficulty of maintaining separate passwords for their Windows and UNIX accounts or having to remember to change the password wherever it is used. With Password Synchronization, whenever a user's password is changed on a Windows computer or domain, the password will also be changed on every UNIX host for which the user has an account. Password Synchronization can even be configured to change the user's Windows password when the user's UNIX password is changed

  • Password Synchronization propagates passwords securely by transmitting only encrypted passwords over TCP/IP sockets. This eliminates the need to use nonsecure methods (such as scripts) to administer passwords remotely. Passwords are also synchronized immediately. This means that, unlike with methods such as rdist, which batches the password propagation, there is no appreciable delay between the time that a password is changed on one system and when it is changed on all other affected systems. Even more important, perhaps, it eliminates a potential security risk if a password needs to be changed to block a user's access to the network. To enhance network security even further, different encryption keys can be used for each Windows computer/UNIX host pair.

  • Password Synchronization is a combination of three software components.

    • The Password Synchronization service running on one or more Windows computers

    • The Password Synchronization daemon running on one or more UNIX computers

    • The Password Synchronization pluggable authentication module (PAM) installed on one or more UNIX computers.

  • Whenever a password is changed on a Windows computer running Password Synchronization, the Password Synchronization service determines whether the user's password is to be synchronized on UNIX computers. If it is, the service encrypts the password and sends it to the Password Synchronization daemon on each computer with which the Windows computer is configured to be synchronized. The daemon then decrypts the password and changes the password on the UNIX host. If the UNIX host is an NIS or NIS+ master server and it is configured to do so, the daemon also runs make to propagate the password change throughout the NIS domain.

  • With Windows SFU 3.0, Password Synchronization can be two-way, allowing passwords that are changed on UNIX hosts to be synchronized on Windows computers and domains. The Password Synchronization PAM makes this possible by intercepting the password change request on the UNIX host, encrypting the password, and then sending the password change request to the Password Synchronization service running on the Windows computers with which it is configured to be synchronized.

    3ovw01

    3ovw02

Coordinating account names and password policies

  • The password policies on both systems must be similar. If the policy on one system is stronger (more restrictive) than that on the other, Password Synchronization might fail to synchronize passwords, and the failure might not be reported

  • This feature may be installed either on domain controllers or on local computers. This allows synchronization of passwords for either domain users or local users respectively.

  • In order to synchronize users' domain passwords with those of Unix computers, password synchronization component must be installed on all Domain Controllers in that domain.

  • In addition, Password Synchronization can only synchronize the passwords of accounts with identical user names. Windows and UNIX administrators must ensure that the user names for the Windows and UNIX accounts of a given user match exactly (including case)

  • If you are configuring Password Synchronization for one-way (Windows-to-UNIX) synchronization, you should consider disabling the ability of users to change passwords on the UNIX hosts that are to be synchronized with the Windows computers. Otherwise, if users change their UNIX passwords, their passwords will no longer be synchronized

Lab 6: 2-Way Windows/UNIX Password Synchronization

Lab Tasks

In this lab you will perform the following tasks:

  • Configure Password Synchronization

  • Exercise 2-Way Password Synchronization

  • Manage Password Synchronization

Exercise 6-1: Configure Password Synchronization

To Configure 2-way Windows/UNIX PASSWORD SYNCHRONIZATION:

  1. Start Services for UNIX Administration.

  2. Click Password Synchronization, and then click the Default tab.

  3. To allow password synchronization from UNIX-based computers to Windows-based computers, click Synchronize password changes from computers that run UNIX to computers that run Windows.

  4. In the Encryption key text box, you can type the key you want to use, or have the program select a key for you by clicking New Key. Accept the default for this exercise.

  5. Notice that the default port specified is 6677. To use a port other than 6677, type the port number in the Port number box.

  6. Click the Advanced tab.

  7. Type the name of the Unix machine to synchronize passwords with, lnxdell, in the Computer name box and click Add.

  8. Click the Configure button

  9. Select Synchronize password changes from lnxdell, and click OK.

  10. To save the new settings, click Apply.

Exercise 6-2: Using 2-Way Password Synchronization

To use 2-way Password Synchronization from both Windows 2000 and Unix Machines.

  1. Logoff as Administrator and Logon as user2 with password user2.

  2. Change your password on Windows 2000 machine. To change the password, press Ctrl + Alt and Delkeys, then select Change Password from dialog box. Remember to make note of the new password.

  3. Telnet to UNIX machine, and verify that now you have to log on to user2 with the new password.

    Note: The password change on Windows was synchronized to your user account on the UNIX machine.

  4. Type the following command at the telnet prompt: tail -n2 /var/log/messages

    You should see output that looks something like (without the bolding):

[user2@lnxdell user2]$ tail -n2 /var/log/messages Apr 20 04:10:17 lnxdell ssod:[3356]: Successfully updated password for user user2 Apr 20 04:10:41 lnxdell PAM_pwdb[3358]: (login) session opened for user user2 by (uid=0) [user2@lnxdell user2]$

  1. Now change your password from the UNIX machine by entering the passwd command (would be yppasswd if an NIS account).

  2. Log off and exit from Telnet session.

  3. Now on Windows machine, verify that your password has been updated by re-logging on to user2.

Exercise 6-3: Manage Password Synchronization

To manage password synchronization using Password Synchronization in Services for UNIX Administration:

  1. Set the default settings that apply to the entire configuration of UNIX-based computers defined for the Windows 2000–based computer or domain. The settings determine what the Event Log displays, the maximum number of times to resend the failed password update, and the time the service waits before resending a password update that has failed.

  2. Add or remove a UNIX-based computer from the list of computers designated to receive password updates.

  3. Create or modify the configuration for the UNIX-based computer, including the custom settings (the default settings applied to that single computer) and the encryption settings for secure communication. The order in which the names of the UNIX hosts appear in the list determines their order in the registry and the order in which they are processed for password synchronization.

To Manage Password Synchronization using Local User Groups in Computer Management:

  1. Create two local user groups called PasswordPropAllow and PasswordPropDeny to control which users' passwords are to be synchronized.

  2. In the PasswordPropAllow group, add the user names for which passwords should be synchronized. In the PasswordPropDeny group, add the user names for which passwords should not be synchronized.

  3. Passwords are synchronized for users who are in PasswordPropAllow and are not in PasswordPropDeny

Interix 2.2 Overview

  • What is Interix?

    • A complete, high-performance environment to run UNIX applications and scripts on Window NT and Windows 2000.

    • The easiest way for customers to take advantage of their previous investments in UNIX-based legacy applications as they move to the Windows platform

  • Benefits

    • Easily run UNIX-based applications and scripts on Windows (over 300 utilities and tools)

    • A Single Enterprise Platform to run all Windows, UNIX, and Internet applications

    • Take advantage of existing UNIX expertise

    • Supports over 1900 UNIX APIs

Interix 3 Lab Objectives

  • Product Walk-Through

  • Porting Examples and Problems

  • Example Windows Integration:

    COM Integration

Exercise 8-1: Setting up Interix v3 Development (Build) Environment

The Interix 3 services are now installed and running. But, you need to fix the Interix development environment to work with version 6.0 of Microsoft Visual C. To do this:

  1. Ensure that the environment variable INTERIX_COMPILERDIR points to the directory where the Microsoft compiler is installed (the path can not include any blanks…so change any pathname components that have blanks to 8.3 file names. e.g. "Program Files"): /dev/fs/C/PROGRA~1/MICROS~4 (Windows path: C:\Program Files\Microsoft Visual Studio) by using Control Panel -> System -> Advanced Tab

  2. This script fragment looks for the two directories in the Microsoft Visual C/C++ 6 directory hierarchy that need to be in the PATH and adds them. Edit the block of code in the /etc/profile file that refers to INTERIX_COMPILERDIR, in an INTERIX 3 system, it looks like this:

if [ "$INTERIX_COMPILERDIR" != "" ]; then # VC/BIN and SharedIDE/BIN are necessary for MSVC5.0 support # because both there directories contain required DLLs for _i in VC98/Bin Common/MSDev98/Bin BIN VC/BIN SharedIDE/BIN; do _i="$(ntpath2posix -c ${INTERIX_COMPILERDIR}/${_i})" if [ -d "${_i}" ]; then export PATH="$PATH:${_i}" fi done unset _i fi

  1. Start a Korn Shell (StartProgramsServices for UNIXInterix ksh) and enter the following:

$ echo $PATH FakePre-e04a383bf1c9493e9825824d639335bc-aecf3fe93d84457a9fc370db5fc2358b

Lab 9: Product Walk-through

Objective

This lab provides an understanding of the various aspects of the Interix software and services. It will walk you through the various aspects of the Interix software and services, and how they interact with the Windows environment. It also cover installing Unix services as Windows services, and reviews commands, shells, the file system, etc.

Lab 9: Product Walk-Through Objectives - Investigate:

  • Commands

  • Shells, remote shells, executables

  • File System

  • Process space

  • Script Engines

  • Simple compilation example

Lab Tasks

In this lab, you will perform the following tasks:

  • Explore Shells, Commands, and Remote Shells

  • Perform System Administration

  • Use Telnet Server

  • Perform a simple compilation example

Exercise 9-1: Exploring Shells, Commands and Remote Shells

As a complete UNIX environment for Windows, INTERIX offers the same standard command shell interface as most UNIX systems. INTERIX provides both the Korn Shell (/bin/ksh) and the Tenex C Shell: (/bin/tcsh). (Note: /bin/csh is a copy of the tcsh.)

Because INTERIX integrates in the Windows NT/2000 environment, INTERIX provides a program group that allows you to start either a ksh or csh shell. To start one of these shells:

  1. Select StartProgramsServices for UNIXInterix ksh or

    StartProgramsServices for UNIXInterix csh

    This will start the INTERIX shell of your choice.

To create a shortcut to your favorite shell:

  1. Press the right mouse button while the mouse pointer is on the desktop, then select NewShortcut

  2. Then for the Desktop shortcut's Command Line, type:

    C:\SFU\common\ksh.bat –l (a lowercase 'L', not a one)

  3. Set the title to Interix ksh

    This will put a shortcut to the INTERIX ksh on your desktop to make it easier to start an INTERIX ksh. You can now double-click on the newly created icon to start your shell.

Now we will try some Interix Korn Shell commands:

  1. To find out the time that the INTERIX subsystem was started and who is currently using the INTERIX environment, type the following at the command prompt:

$ who –a System Boot CPU Apr 19 11:04 Administrator ttyn00 Apr 20 10:01 $

  1. Type the following to find out who is currently using the INTERIX environment:

$ who am I Administrator ttyn01 Apr 20 10:01 $

  1. To display the current time, type the following at the command prompt:

$ date Tue Apr 23 10:18:02 PST 2002 $

  1. You can execute several commands on the same line by typing a semicolon (;) between them. For example:

$ who am i;date Administrator ttyn01 Apr 20 10:01 Tue Apr 23 10:19:04 PST 2002 $

  1. INTERIX provides full job control in all of its shells. For example, to create a listing of all the files on your computer, type the following at the command prompt:

$ ls -R /

output will start to display, to stop this, simply press Control-C.
  1. To take the output of our "ls" command and redirect it to a file, type the following at the command prompt:

$ ls -R / > ls.out

  1. As you notice, the command prompt does not return because the ls process is still running. To stop the ls process, type Control-Z. The following will be displayed:

$ ls -R / > ls.out [1] + Stopped ls -R / $

  1. This ls process is now paused, we can start the ls process up again, kill the ls process, or if we want to get our command prompt back, we could put this ls process in the background:

$ bg [1] ls -R / $

  1. This will continue the ls process from where it was paused and the output from the ls process will continue to be directed to the ls.out file. We can see which "jobs" we have running using the jobs command:

$ jobs [1] + Running ls -R / $

  1. This tells us that the ls -R / process is still running, but we can continue to do other things with our command prompt. To stop the job (process) forever, we can issue the "kill" command:

$ kill %1 $[1] + Terminated ls -R / $

The ls process is now terminated. However, the ls.out file is still present and contains all of the output of the ls process until the time when the process was killed.
  1. To see the content of the ls.out file, type the following at the command prompt:

$ cat ls.out | pg

The contents of the file are displayed one page at a time. You can press Control+C or enter "q" (without the quotes) to stop viewing the file.
  1. To view a specific section of the file, type the following at the command prompt:

$ tail -n20 ls.out (to see the last 20 lines of the file) $ head -n20 ls.out (to see the first 20 lines of the file)

INTERIX also supplies the link command (ln). This allows a single file to have many names, which is beneficial if you have a file that you want to share with many people in different directories. Linking the file enables you to have the same file in multiple locations without actually copying the file.

**Note:** Interix 3 supports both hard and symbolic links. For our purposes here, we're only examining hard links.
  1. Enter the following to obtain a better understanding of the link command:

$ touch file $ ln file FILE $ ln FILE File (we can even link from the link) $ ls -il [Ff][Ii]* 30632 -rw-r--r-- 3 Administrator Administrators 10 Apr 20 14:27 FILE 30632 -rw-r--r-- 3 Administrator Administrators 10 Apr 20 14:27 File 30632 -rw-r--r-- 3 Administrator Administrators 10 Apr 20 14:27 file $

The ls -il command shows the file modes, owner, group and the file serial number or inode (the first column) that identifies these particular files. As you can see, the numbers are the same, and even more interesting, INTERIX provides complete case sensitivity where files named file, FILE, and File can reside in the same directory\! (Also notice the count of three for the number of "links" to the same inode.)
  1. INTERIX provides man pages for all its commands; for example type the following at the command prompt:

$ man cat

  1. To "pipe" output from one command to the other, type the following at the command prompt:

$ ls -l /bin | sort +4n

  1. As you will notice, this puts the files of the INTERIX bin directory in ascending size order. If you want to see the largest 3 files in a directory, the following would be one way to do this:

$ ls -l $INTERIX_ROOT/bin | sort +4n | tail –4 -rwxrwxrwx 1 Administrators Domain Users 431616 Nov 27 1998 tcsh -rwxrwxrwx 1 Administrators Domain Users 431616 Nov 27 1998 tcsh.exe -rwxrwxrwx 1 Administrators Domain Users 531456 May 15 1998 strip total 38128 $

  1. Both INTERIX ksh and csh provide the ability to "alias" an application to an easily remembered (or typed) name. To create an alias for a Win32 character-based command to an INTERIX command, enter the following at the command prompt:

$ alias attrib=/dev/fs/C/WINNT/system32/attrib.exe $ attrib

  1. A full set of shell "wrappers" has been created in /usr/contrib./win32/bin for Windows programs. To see how many:

$ ls -1 /usr/contrib/win32/bin | wc –l 143 $

  1. One of the large number of NT commands that is wrapped is notepad, try it by entering:

$ notepad &

This will start the Win32 notepad. Note that you can do this with most Win32 applications including Microsoft Word and Excel – just take one of the existing shell wrappers and make a copy of it and change to point to your Word or Excel programs.

Exercise 9-2: Perform System Administration

With INTERIX, you can use the Windows NT/Windows 2000 command lines utilities to create local user accounts. For these examples we will use the net.exe utility.

  1. Interix ships with a shell wrapper for net already. To see this, at the command prompt:

$ whence net /usr/contrib/win32/bin/net

  1. Let's say that you need to create an account for Tom. To do this, type the following at the command prompt:

$ net users tom Mypass911 /COMMENT:"comment" /HOMEDIR:"C:\users\tom" /ADD

**Note:** When specifying a home directory make sure that you use "\\\\" instead of "\\".
  1. Enter the following to verify that the command executed successfully:

$ net users tom

You will see the following on the console:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

User name tom Full Name Comment comment User's comment Country code 000 (System Default) Account active Yes Account expires Never Password last set 4/24/2001 8:44 AM Password expires 6/6/2001 7:32 AM Password changeable 4/24/2001 8:44 AM Password required Yes User may change password Yes Workstations allowed All Logon script User profile Home directory C:\users\tom Last logon Never Logon hours allowed All Local Group Memberships Global Group memberships *Domain Users The command completed successfully.

  1. To delete a user account enter the following:

$ net users tom /delete

The command completed successfully.
  1. To verify that the user account tom is indeed deleted, type:

$ net users tom

The user name could not be found.

**Note:** For more information on net.exe, type NET HELPMSG 2221 at the command prompt.
  1. It is also possible to see the resource usage of a system by using the same commands as on a "standard" UNIX system (this list will vary depending on system, and notice the list includes any nfs mounts):

$ df –k

<table style="width:100%;">
<colgroup>
<col style="width: 14%" />
<col style="width: 14%" />
<col style="width: 14%" />
<col style="width: 14%" />
<col style="width: 14%" />
<col style="width: 14%" />
<col style="width: 14%" />
</colgroup>
<thead>
<tr class="header">
<th><p>Filesystem</p></th>
<th><p>1024-blocks</p></th>
<th><p>Used</p></th>
<th><p>Available</p></th>
<th><p>Capacity</p></th>
<th><p>Type</p></th>
<th><p>Mounted on</p></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><ul>
</ul>
<p>///HarddiskVolume1</p></td>
<td><ul>
</ul>
<p>2048255</p></td>
<td><ul>
</ul>
<p>286125</p></td>
<td><ul>
</ul>
<p>1762130</p></td>
<td><ul>
</ul>
<p>14%</p></td>
<td><ul>
</ul>
<p>ntfs</p></td>
<td><ul>
</ul>
<p>//C/</p></td>
</tr>
<tr class="even">
<td><ul>
</ul>
<p>///HarddiskVolume2</p></td>
<td><ul>
</ul>
<p>6144860</p></td>
<td><ul>
</ul>
<p>3786368</p></td>
<td><ul>
</ul>
<p>2358492</p></td>
<td><ul>
</ul>
<p>62%</p></td>
<td><ul>
</ul>
<p>ntfs</p></td>
<td><ul>
</ul>
<p>//D/</p></td>
</tr>
<tr class="odd">
<td><ul>
</ul>
<p>///HarddiskVolume3</p></td>
<td><ul>
</ul>
<p>7164956</p></td>
<td><ul>
</ul>
<p>4918292</p></td>
<td><ul>
</ul>
<p>2246664</p></td>
<td><ul>
</ul>
<p>69%</p></td>
<td><ul>
</ul>
<p>ntfs</p></td>
<td><ul>
</ul>
<p>//F/</p></td>
</tr>
<tr class="even">
<td><ul>
</ul>
<p>///HarddiskVolume5</p></td>
<td><ul>
</ul>
<p>2112512</p></td>
<td><ul>
</ul>
<p>1573436</p></td>
<td><ul>
</ul>
<p>539076</p></td>
<td><ul>
</ul>
<p>74%</p></td>
<td><ul>
</ul>
<p>ntfs</p></td>
<td><ul>
</ul>
<p>//H/</p></td>
</tr>
<tr class="odd">
<td><ul>
</ul>
<p>/tmp/LinuxProg</p></td>
<td><ul>
</ul>
<p>1817568</p></td>
<td><ul>
</ul>
<p>679136</p></td>
<td><ul>
</ul>
<p>1138432</p></td>
<td><ul>
</ul>
<p>37%</p></td>
<td><ul>
</ul>
<p>nfs</p></td>
<td><ul>
</ul>
<p>//I/</p></td>
</tr>
</tbody>
</table>
  1. To display the size of user files enter:

$ du -sk /users/* 458 /users/tom

Note: All of these examples can also be run by telneting into the NT/2000 machine and running the commands remotely. See how to start the Telnet daemon later in this lab.

Exercise 9-3: Use Telnet Service

In this lab exercise, you will learn to install the INTERIX telnetd program as a Windows NT/2000 system service. The telnetd program accepts inbound requests from telnet clients allowing for multi-user login support. This is the same procedure for installing any service.

  1. Start a Korn Shell (ksh) and enter the following command at the prompt:

$ vi /etc/inetd.conf

  1. In vi, type:

/#telnet

to go to the line that has the telnet daemon commented out.
  1. Press "x", without the quotes, to delete the # sign, then <Esc>:wq to save and quit vi.

  2. First, use the Microsoft Service Manager to make sure that the Win32 Microsoft Telnet Service isn't already running. If it is, stop it and set it to Manual startup.

  3. Tell inetd to reload its configuration file (by issuing a kill -1 to the inetd process):

kill -1 $(ps –ef | grep inetd | grep –v grep | tr –s " " | cut –f2 –d" ")

  1. Next, run the Microsoft telnet client (StartProgramsAccessoriesTelnet). Connect to localhost and you will be presented with a login prompt. Login as any known Windows user. You can a domain account (username), since the default domain will be added. Note: Next, login from the remote Linux machine ( lnxdell ) on the network to the INTERIX Server. You will need to specify the server hostname (w2ksgw.gwtwork.com) from the remote Linux machine. From the telnet shell you will be able to run any shell command. You can also run an X Windows application from the remote machine and display it on your local machine (assuming you have an X server running on that machine). For example to run xclock, type:

$ xclock -display hostname:0 &

where hostname is the name of the machine you have logged in from.

Note: In the context of this lab, we do not have an X server installed, so this portion of the demo will not function.

Exercise 9-4: Perform a simple compilation example

In this lab exercise, you will learn to build a standard UNIX application using the awk script language in the INTERIX Software Development Kit.

Perform the following steps to compile a standard UNIX application:

  1. Navigate to the directory for building the demo application by entering:

cd /usr/examples/gawk

  1. Show Display the number of lines of code by typing the following at the command prompt:

$ wc -l *.h *.c

**The following list is displayed when you execute the wc command:**

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

758 awk.h 272 config.h 543 dfa.h 128 getopt.h 1 patchlevel.h 115 protos.h 260 regex.h 206 alloca.c 293 array.c 3243 awktab.c 1131 builtin.c 2291 dfa.c 1225 eval.c 648 field.c 662 getopt.c 160 getopt1.c 1208 io.c 318 iop.c 731 main.c 89 missing.c 94 msg.c 429 node.c 207 re.c 2854 regex.c 40 testarg.c 46 version.c 17952 total $

  1. To build the Unix application, type the following command:

$ make clean; make gawk

The following list is displayed when you execute the command:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

rm -f main.o eval.o builtin.o msg.o iop.o io.o field.o getopt1.o getopt.o array.o alloca.o node.o version.o missing.o re.o awktab.o regex.o dfa.o gawk c89 -O -I. -DGAWK -D__OPENNT -c main.c c89 -O -I. -DGAWK -D__OPENNT -c eval.c c89 -O -I. -DGAWK -D__OPENNT -c builtin.c c89 -O -I. -DGAWK -D__OPENNT -c msg.c c89 -O -I. -DGAWK -D__OPENNT -c iop.c c89 -O -I. -DGAWK -D__OPENNT -c io.c c89 -O -I. -DGAWK -D__OPENNT -c field.c c89 -O -I. -DGAWK -D__OPENNT -c getopt1.c c89 -O -I. -DGAWK -D__OPENNT -c getopt.c c89 -O -I. -DGAWK -D__OPENNT -c array.c c89 -O -I. -DGAWK -D__OPENNT -c alloca.c alloca.c(206) : warning C4715: 'xmalloc' : not all control paths return a value c89 -O -I. -DGAWK -D__OPENNT -c node.c c89 -O -I. -DGAWK -D__OPENNT -c version.c c89 -O -I. -DGAWK -D__OPENNT -c missing.c c89 -O -I. -DGAWK -D__OPENNT -c re.c c89 -O -I. -DGAWK -D__OPENNT -c awktab.c c89 -O -I. -DGAWK -D__OPENNT -c regex.c c89 -O -I. -DGAWK -D__OPENNT -c dfa.c c89 -o gawk main.o eval.o builtin.o msg.o iop.o io.o field.o getopt1.o getopt.o array.o alloca.o node.o version.o missing.o re.o awktab.o regex.o dfa.o -lm $

  1. To display the type of executable that has been built, type:

$ file gawk

gawk: DOS executable (EXE) Windows NT PE format, executable not stripped Intel Posix-CUI
  1. Execute the newly created gawk program, type:

$ ./gawk

The following list is displayed when you execute the gawk program:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

Gnu Awk (gawk) 2.15, patchlevel 2 usage: gawk [POSIX or GNU style options] -f progfile [--] file ... gawk [POSIX or GNU style options] [--] 'program' file ... POSIX options: GNU long options: -f progfile --file=progfile -F fs --field-separator=fs -v var=val --assign=var=val -W compat --compat -W copyleft --copyleft -W copyright --copyright -W help --help -W lint --lint -W posix --posix -W source=program-text --source=program-text -W usage --usage -W version --version $

  1. To execute the gawk program (version 3.0.4) on the lnxdell Linux 6.1 system via telnet session, type:

[user2@lnxdell user2]$ gawk Usage: gawk [POSIX or GNU style options] -f progfile [--] file ... gawk [POSIX or GNU style options] [--] 'program' file ... POSIX options: GNU long options: -f progfile --file=progfile -F fs --field-separator=fs -v var=val --assign=var=val -m[fr] val -W compat --compat -W copyleft --copyleft -W copyright --copyright -W help --help -W lint --lint -W lint-old --lint-old -W posix --posix -W re-interval --re-interval -W source=program-text --source=program-text -W traditional --traditional -W usage --usage -W version --version Report bugs to bug-gnu-utils@gnu.org, with a Cc: to arnold@gnu.org [user2@lnxdell user2]$

Notice that the output is very similar. Differences are due to the version levels of gawk on each of the systems.

Interix 3Porting

  • Caveats of Porting

    • Open Systems (e.g. SVR4 or BSD) Shell Scripts Porting Caveats

    • Porting Applications Written in C Overview

    • Porting Applications Written in C Caveats

Caveats of Porting

Open Systems (e.g. SVR4 or BSD) Shell Script Porting Caveats:

  • Most shell scripts from a traditional UNIX system work because pathname notation, $PATH, and #! Notation is all supported along with proper device names such as /dev/null.

  • $PATH separation is accomplished using ":"

  • Several useful tools are provided by Interix to allow powerful scripts to be built around Win32 based executables:

    • chgpath: converts between path syntax styles

    • cat32: used to handle poorly constructed Win32 command line tool output

    • wvisible: tests whether the user is running on the root window. (Prevent them from running a Win32 GUI app on a telnet session)

    • runwin32: Runs entire command lines from the Win32 world managing command line syntax conversions.

  • By default, Interix stores binaries in one of two directories: /bin and /usr/contrib, plus /usr/X11R5/bin and /usr/contrib/win32/bin for X11 and Win32 binaries, respectively. Any shell script which resets the PATH to a value such as /bin:/usr/local/bin will still find the Interix binaries.

  • Any scripts that rely on information from /etc/passwd or /etc/group (e.g. grep for a username) will need to be modified to use other techniques to obtain information about a user (e.g. Win32 ADSI scripts or net users)

  • Some problems with case sensitive of filenames through NFS mounts

Porting Applications Written in C Overview

The Interix subsystem is a POSIX.1-conformant subsystem. It supports sockets, BSD 4.4 interfaces, System V IPC mechanisms, pseudo terminals, memory mapped files, and much more.

The typical porting process is to type make in the source directory and then fix the problems as the compiler reports them. The most common changes required are:

  • Select the appropriate compile flags for a POSIX.1 system

  • Replace the varargs macros with stdarg macros

  • Isolate the struct stat members st_rdev, st_blksize, and st_blocks.

A set of ported sources are installed in /usr/examples. For each file that required changes from the publicly available source, a diff file has been included. We already compiled, linked, and executed the gawk example in the Lab 9: Exercise 9-4.

Porting Applications Written in C Caveats:

  • Any program that use syscall()

  • Programs that get or set resource management limits (e.g. getrlimit, setrlimit) are not completely supported, or may not supported at all (e.g. resource.h does not exist in the SDK, but Xresource.h does)

  • Any program that digs around in kernel memory (/dev/kmem)

  • Performing ioctl or ioperm sorts of operations on anything that isn't a terminal or modem on a port

  • Programs that expect to perform raw i/o on a device (e.g. floppy, cdrom, hard drive)

  • "Chatting" on the parallel port

  • Reliance on threads (e.g. apache 2.0)

Lab 10: Interix 3 Porting Examples

  • Xtetris

  • Simple-rooted filesystem

  • Script that needs a simple change

  • Failure example!

Overview

The Lab will demonstrate how to port applications from the Unix-only environment to the Windows 2000-Interix environment. The examples are meant to give a broad understanding of the concepts involved in porting applications and do not include all possible variations and/or problems associated with porting.

The Interix SDK provides the compiler interfaces cc, c89, gcc, and g++. To use cc, c89, you must already have Microsoft Visual C/C++ setup and running because cc and c89 invoke the MSVC utilities CL.EXE and LINK.EXE by searching your path for the programs (refer to Lab 1: Exercise 2). This is the case for these labs. The Interix header files work with both the MSVC and gcc compilers. You must use the g++ interface to compile C++ code (there will not be any C++ examples in this lab).

The last exercise, Failure Example, is designed to fail intentionally. One of the goals is to allow the user to determine in a short amount of time whether or not Interix is the ideal solution for their particular situation. It is non-productive for a user to spend many hours working on porting an application if in the end it will never work.

Porting Examples

  • Xtetris

  • Simple-rooted filesystem

  • Script that needs a simple change

  • Failure example!

Lab Tasks

In this lab you will perform the following tasks:

  • Porting Xtetris

  • Porting a Single-Rooted File System depend application

  • Porting a Script that needs a simple change (header or API)

  • Porting an application that needs a simple change (header or API)

  • Failure Example!

Exercise 10-1: Porting Xtetris

In this lab exercise, you will learn to build a X-Client application - the Xtetris game - with the INTERIX Software Development Kit.

Perform the following steps to compile the X-Client UNIX application:

  1. Navigate to the following directory for building the demo application:

cd /usr/X11R5/examples/xtetris-2.6

  1. To display the number of lines of code, type the following command:

$ wc -l *.h *.c

**The following list is displayed when you execute the command:**

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

97 defs.h 62 draw.c 81 init.c 264 main.c 247 notify.c 194 score.c 237 shape.c 133 support.c 88 window.c 1403 total

  1. To build the X-Client's make file (Makefile), type:

$ xmkmf

  1. To build the X-Client application, type:

$ make xtetris; make depend; make install

The following list is displayed when you execute the command:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">

$ make xtetris;make depend;make install gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c ma in.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c in it.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c sh ape.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c su pport.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c no tify.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c wi ndow.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c sc ore.c gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -I/usr/X11R5/inc lude -Dopennt -DHIGH_SCORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -c dr aw.c rm -f xtetris gcc -fstrength-reduce -fpcc-struct-return -O -O -D_ALL_SOURCE -static -L/usr/X1 1R5/lib -o xtetris main.o init.o shape.o support.o notify.o window.o score.o draw.o -lXaw -lXmu -lXt -lXext -lX11 -lm makedepend -s "# DO NOT DELETE" -- -I/usr/X11R5/include -Dopennt -DHIGH_SC ORE_TABLE="/usr/X11R5/lib/X11/xtetris-scores" -- main.c init.c shape.c suppor t.c notify.c window.c score.c draw.c FakePre-a987a9efa2ac40618d8b83c5e72a2550-143eb54785a044c4b30f26ff19d5e37e

  1. To display the type of executable that has been built, type:

$ file xtetris xtetris: Windows NT PE format (EXE), executable not stripped Intel Posix-CUI

  1. To execute the newly created gawk program, type:

$ ./xtetris or xtetris (since it was also installed in the /usr/X11R5/bin directory)

(Have Fun…But not to much! J)

1 User Name Mapping does not authenticate UNIX NFS requests sent to Server for NFS. Server for NFS uses Server for NFS Authentication component for authenticating NFS requests from UNIX clients.