Services for UNIX Configuration

Now that you've installed SFU, let's look at its configuration. There are three basic groups of services to the SFU product, all of which you configure from the Services for UNIX Administration MMC, shown in Figure 22-4. The exception is Gateway for NFS, which is primarily configured using the Gateway for NFS configuration application shown in Figure 22-5.

Figure 22-4. The main screen of the Services for UNIX Administration MMC snap-in.

Figure 22-5. The main screen of the Gateway for NFS configuration application.

The three groups are as follows:

• Connectivity services Includes a Telnet server and an improved, text-based (character-mode) Telnet client, remote shell services, password synchronization, a User Name Mapping server, and Server for NIS.
• File services Includes Client for NFS, Server for NFS, Gateway for NFS, and PCNFSD Server.
• Interoperability and migration services Includes the Interix subsystem, Base Utilities, and SDK; UNIX and ActiveState Perl distributions; and the GNU Utilities and SDK.

Connectivity Services

Services for UNIX version 3.0 includes two completely different Telnet server/client combinations. The main Telnet server and client are Win32 based and are similar to those included with Windows 2000 (and virtually identical to the ones included with Microsoft Windows XP), with the important exception that the version included in SFU supports up to 10 connections on Windows NT 4 Workstation and Windows 2000/XP Professional and up to the maximum number of client access licenses on Windows NT/2000. Alternatively, there is a separate telnetd (Telnet daemon, or service in Windows-speak) and Telnet client included as part of the Interix subsystem and controlled as part of inetd.

Only one Telnet server can be running at a time. By default, the Interix telnet daemon is disabled in /etc/inetd.conf. To enable it, first disable the regular Telnet server using the Windows Services MMC and then uncomment the line in inetd.conf that reads:

 #telnet stream tcp nowait NULL /usr/sbin/in.telnetd in.telnetd -i 

Then issue a NOHUP to inetd :

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

Alternatively, the next time you reboot the system, the change to inetd takes effect.

Either Telnet client or server provides an excellent method for communicating between Windows 2000 machines and UNIX machines. However, the Telnet services can also offer substantial benefits in daily administration of the Windows 2000 machines themselves. By adding a Telnet service to your Windows 2000 servers, you provide a simple, low-overhead command-line interface to the servers that lets you easily manage a variety of administrative tasks from a single desktop and even over a slow dial-up line.

The Telnet Server

As installed, the Win32 Telnet server works optimally for most installations. It provides access from any server or workstation that has a Telnet client installed, offering improved interoperability in the enterprise and improved manageability even in a pure Windows 2000 environment. It accepts login from a variety of clients, including the graphical Telnet client shipped with Windows NT and Microsoft Windows 95/98 and a variety of character-mode terminal clients from virtually any operating system. Additionally, it can meet specific site requirements to improve security, simplify login, and so on.

The NT LAN Manager The SFU Telnet server supports NT LAN Manager (NTLM) for authentication of client logins. NTLM automatically authenticates the user based on his or her Windows 2000 logon, giving a transparent connection to the host while ensuring that clear text passwords don't pass over the network. NTLM must be supported on both the client and server side however, making this option viable only between Windows machines, not directly to or from UNIX machines.

When using NTLM login, users are restricted to local drives on the machine they are logged on to. If they need to map network resources, they can do so by explicitly mapping with full credentials. For example,

net use g: \\server\share /user:domain\username.

Administration The Telnet server is administered by using the Tnadmin.exe program, which is installed by default in <SFU Root>\common, or with the Services for UNIX Administration MMC snap-in. To see the options for Tnadmin.exe, type tnadmin /?.

The available options that can be set are as follows:

• Authentication Choices are NTLM and Username/Password.
• Auditing Set event logging to a separate log file, or the event log, and set what events to log.
• Server Settings Set the following options:
  • Maximum Number Of Simultaneous Connections Default is the number of licensed connections to the server. On Windows XP Professional, the default is 1.
  • Maximum Number Of Failed Login Attempts Default is 3.
  • Map Alt Key To CtrlA Default is Yes.
  • Telnet Port Default is 23.
  • Mode Of Operation Choose Console or Stream. The default value is Console.
  • Default Domain Name Type in a domain name that is automatically added to the logon user name. The default is ".", which disables this feature.
  • Idle Session Timeout Time until an idle session is forcibly disconnected.
  • Terminate All Programs When Disconnecting A toggle with the next option.
  • Continue To Run Programs Started With Bgjob Command Allows jobs to continue to run after the session has ended.
• Sessions Allows you to see data about the currently active sessions (like user, domain, machine, logon date/time) and either send a message to the session or terminate it.

The Telnet Client

Whereas Windows NT comes with a familiar graphical-mode Telnet client, Windows 2000 includes the new character-mode Telnet client that originated in SFU. It provides greatly improved scroll bars and the ability to authenticate using encrypted passwords when connecting to Telnet servers that support NTLM authentication. It is both faster and better behaved than the graphical-mode client it replaces. The version included with Services for UNIX version 3.0 also supports both stream mode and console mode and has additional configuration options that let you tune it for individual situations. This character mode client is installed on Windows NT systems as Telnetc.exe in the System32 folder.

Furthermore, the character-mode Telnet client in Windows 2000 and Services for UNIX provides terminal emulations, including an ANSI emulation that supports colors correctly when connecting to servers that support it. There is also a new VTNT emulation that supports enhanced features when connecting between Windows machines—including the ability to run complex character-mode applications such as Edit.exe that won't work with standard terminal emulations.

The Telnet client configuration is done from within a telnet session by "escaping" to the telnet prompt. Press Ctrl + right bracket (]) to bring up the telnet prompt once you've started a telnet session. From here, you can use the following commands:

• ? To get help.
• close To close the current connection.
• display To show the current operating parameters.
• open <machinename> To open a connection to a machine (you can use an IP address here as well).
• send To send strings to the Telnet server. The strings are sent as is, except for the following special strings:
  • ao Send the telnet command "Abort Output" to the server.
  • ayt Send the telnet command "Are You There" to the server.
  • esc Send the telnet escape character to the server.
  • ip Send the telnet command "Interrupt Process" to the server.
  • synch Send the telnet command "Synch" to the server.
• status To print basic status information about the current session.
• quit To exit the Telnet client completely.
• set To set an operating parameter. This takes the following parameters:
  • ? Get help on other set options.
  • bsasdel Backspace key is sent as the Delete key.
  • crlf Return key sends both a carriage return and a linefeed (0x0D,0x0A).
  • escape x x is the escape character to enter the Telnet client prompt (default is ^]).
  • localecho Turns on local echo of characters typed.
  • logfile <filename> Sets filename to be the current log file.
  • mode x Where x is console or stream.
  • ntlm Turns on NTLM authentication.
  • term <value> Sets the requested terminal emulation. Choices are ANSI, VT52, VT100, and VTNT.
• unset To unset the options set with the set command.

Real World

Terminal Emulation Choices

If you connect primarily to UNIX systems, set TERM to ANSI (and set NTLM off), but if you connect frequently to both Windows NT/2000 and UNIX systems or primarily to Windows NT/2000 systems, you'll find the VTNT emulation a better choice, and you'll still fall back to ANSI when connecting to a system that doesn't support VTNT.

File Services

SFU provides additional file service connectivity beyond the native FTP client and server in Windows 2000. The addition of NFS client, server, and gateway products allows native connectivity in a way that looks and feels natural to both UNIX and Windows 2000 users.

By using the seamlessly integrated NFS client, you can map exported file systems from your UNIX servers just as if they were native Windows 2000 shares, using either the UNIX server:/export format or the Windows \\server\share format. The NFS server also allows you to share the file resources with your UNIX systems or with other NFS clients, including Windows 2000 clients. Let's look at NFS client first.

You cannot install both Client for NFS and Gateway for NFS on the same computer; they are mutually exclusive.

The NFS Client

When you install the NFS client, it adds another set of options to the Services for UNIX Administration snap-in. The following sections detail the options you can select to administer the NFS client settings.

File Access Permissions The default file access permissions for the NFS client are Read, Write, and Execute for the user (owner) of the file, but only Read and Execute for the Owner group and for other users (equivalent to a umask of 022), as shown in Figure 22-6. You can adjust the defaults for all users here.

Figure 22-6. The default file permission settings for the Client for NFS.

Performance Settings You can change several performance-related settings of Client for NFS from the SFU Administration snap-in, as shown in Figure 22-7. The default values for these settings are as follows:

• Transport protocol UDP
• Mount Type Soft
• Maximum Number Of Retries For Any Operation 1
• Interval Between Retries 0.8 seconds
• Read Buffer Size 32 Kb
• Write Buffer Size 32 Kb

Figure 22-7. Performance options for Client for NFS.

Connecting to an NFS Export You can connect to an NFS export using either standard Windows syntax (\\server\share) or standard UNIX syntax (server:/share). From the command line you can use the standard Windows NT/2000 Net commands, or the more UNIX-like mount command with either syntax. Or simply browse your Network Neighborhood in Windows Explorer. From the command line, the following commands are equivalent:

 net use * server1:/home
net use * \\server1\home
mount server1:/home *
mount \\server1\home * 

When you are sure you are connecting to an NFS export, use the UNIX server:/share syntax for faster setup of the connection.

Symbolic Links Symbolic links are a way for a file or directory to exist in one physical location but appear to be in another location or locations. All operations except rename and delete (or their Interix equivalents—mv and rm—are redirected to the target of the symbolic link. For Client for NFS to resolve a symbolic link, the user must have permission to access the target file or directory. When listing directories that contain symbolic links, Client for NFS always displays the attributes for the actual file or directory, not the link.

Gateway for NFS

Services for UNIX version 3.0 includes the Gateway for NFS product, which lets you create a regular Windows shared drive that actually points to an NFS export on any NFS server on your network. Basically, the gateway computer acts as an NFS client to the NFS server but then maps that to a drive letter on the gateway computer that can be shared with other Windows clients on the network.

Gateway for NFS provides an easy way to provide access to NFS exports without having to install Client for NFS on every machine that needs access; no additional software is required for the client machines. However, although this is a simple and appropriate solution for casual and occasional access, it should not be the mechanism of choice for the power user or frequent NFS user. These users should have individual copies of SFU, including Client for NFS, loaded locally on their machine. There is also another limitation: each gateway computer can only provide access to as many NFS exports as it has free drive letters.

Gateway for NFS uses its own graphical application for administration, as shown in Figure 22-5. You can also configure it from the command line using the Nfsadmin.exe application.

Server for NFS

Services for UNIX includes the Server for NFS application to provide resources from your Windows 2000 machines to any machine on your network that supports NFS. You can even use it to export file systems to other Windows 2000 machines running Client for NFS, although we generally recommend that you stick to native Windows 2000 networking for that. The following sections describe the options available for NFS configuration.

Server for NFS is administered from the SFU Administration MMC snap-in, as shown in Figure 22-8, except for creating and managing shares, which is done from Windows Explorer. For Server for NFS you can set the following options:

• Logging The size and location of the logging file, and the operations to audit
• Locking The grace period for locks and a list of current locks
• Client Groups Used to group client machines for easier setting of permissions
• Server Settings Used to set various performance and connectivity options

Figure 22-8. Server for NFS logging options.

Shares Create shares by selecting the NFS Sharing tab from the Properties dialog box using Windows Explorer as shown in Figure 22.9. You can share either individual directories or entire drives. To share a directory from the command prompt, type nfsshare sharename=drive:path, where drive:path is the location of the folder you want to share. You can't share a subdirectory of an already shared resource, because NFS doesn't support this, so you'll want to plan your shares to make sure you share from as far up the tree as necessary. Each drive letter is shared as the top of a file system.

Figure 22-9. Sharing a folder using Server for NFS.

Permissions Server for NFS uses discretionary access control lists (DACLs) to simulate the permissions that are typical in the UNIX and NFS world. The default permissions are Read/Write for all users.

To set permissions, open the Properties dialog box for the folder you are sharing, click the NFS Sharing tab, and then click Permissions.

Real World

NFS Doesn't Support Multilevel Exports

The NFS protocol doesn't support sharing the subdirectory of an already shared resource, so you'll need to ensure that you share from as far up the tree as necessary, because you won't be able to then share another folder within that directory structure. The one exception to this is that each drive letter is shared as the top of a file system.

Interoperability and Migration Services

UNIX and Linux users expect a bevy of command-line utilities and scripting abilities that don't exist in the Windows 2000 world. Services for UNIX version 3.0 provides just about everything the UNIX/Linux user or administrator expects, including more than 350 command-line utilities, both Korn and C shells, and Perl 5.6, all running in the Interix subsystem.

In addition to the command-line and scripting features, though, the Interix SDK included with SFU version 3.0 takes the interoperability and migration features to a whole new level by providing the ability, through the more than 1900 UNIX APIs that are supported in Interix, to retarget and recompile UNIX and Linux applications to run natively on Windows 2000.

For additional information on the Interix subsystem and the interoperability and migration features that it supports, see the Services for UNIX home page at http://www.microsoft.com/windows/sfu.