Windows NT Services for UNIX

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Server Operating System

Abstract

The Microsoft Windows NT Services for UNIX Add-On Pack makes it easier for customers to integrate the Windows NT Workstation 4.0 and Windows NT Server 4.0 operating systems with their existing UNIX-based workstations and servers by providing access to core interoperability components in an integrated, fully supported package. Benefits include lower deployment costs, improved support for mixed environments, and the most complete integration with current and future Windows NT-based technologies and initiatives.

Introduction

Features

Windows NT Services for UNIX (SFU) provides a comprehensive set of additional features to Windows NT that allow for greater interoperability with existing UNIX servers in the enterprise. These additional features fall into three basic categories:

File Servicesincludes both Network File System (NFS) client and (on Windows NT Server) NFS server support, allowing you to both use existing UNIX file system resources and to make your Windows NT Server file system resources available to UNIX clients.
Connectivity ServicesIncludes both a telnet server and an improved, text-based telnet client, along with a password synchronization daemon that gives you a single point of password management across both Windows NT- and UNIX-based systems.
Usability Servicesprovides a set of UNIX utilities and a Korn Shell to give the UNIX user and administrator a familiar (but limited) subset of the utilities and shell features that most UNIX users take for granted.

File Services

Windows NT Services for UNIX provides full support, both client and server, for an additional network file redirectorNFS.

NFS Client

When installed on either Windows NT Workstation or Windows NT Server, SFU provides a seamlessly integrated NFS client. You can map exported filesystems from your UNIX servers just as if they were native Windows NT shares, using either the UNIX server:/export format, or the Windows \\server\share format.

NFS Server

When installed on a Windows NT Server or Windows NT Workstation the NFS server allows you to share the file resources out to your UNIX systems or to other NFS clients.

Connectivity Services

Telnet Client

Adds a text mode telnet client to the default graphical telnet client. The new client provides improved emulation and the ability to authenticate using encrypted passwords (NTLM) when connecting to telnet servers that support NTLM authentication.

Telnet Server

Provides a full, fast telnet server that can be used to provide access from any server or workstation that has a telnet client installed, providing for improved interoperability in the enterprise, and improved manageability even in a pure Windows NT-based environment.

Usability Services

UNIX Utilities

Provides a limited set of UNIX command line utilities based on the MKS Toolkit, including the MKS KornShell.

Password Synchronization

Provides for synchronization of passwords across Windows NT- and UNIX-based servers. There are pre-compiled versions of the synchronization daemon for HP-UX, SunOS, and Digital UNIX, along with full source code to compile on other UNIX platforms.

Configuring And Using

Once Windows NT Services for UNIX is installed, there are several essential steps to configure it efficiently for your environment.

File Services

Traditionally, UNIX uses the Network File System (NFS) for the sharing of disk resources across a network. Services for UNIX includes both a client and a server for NFS. The default installation of SFU installs both the NFS client and server on a Windows NT Server-based machine and the NFS client on an Windows NT Workstation-based computer. To add the NFS server to Windows NT Workstation, do a custom install.

NFS Client

Configuring the client

When the Services for UNIX NFS Client is installed, it adds a Control Panel applet that allows you to administer the client settings.

Authentication

Set your authentication options according to the type of UNIX system and environment you'll be connecting to. In large enterprises where you are using NIS already on the network, you should select NIS as your authentication mechanism. In environments where NIS is not being used, select PCNFSD ( PC NFS daemon) and designate the server to use for authentication. You can also specify whether to automatically authenticate to the server at logon, or only when you actually attempt to use an NFS resource. The choice here is longer logins versus longer initial access times when you actually use an NFS export.

MountOptions

The NFS Client allows you to specify the size of read and write buffers (default is 64K), initial timeout, number of retries and whether to use hard or soft mounts. Additionally, you can enable NFS version 3 caching if your NFS server supports it, along with enabling file locking and local caching.

Tip Enabling Version 3 caching can provide a significant performance boost, but should only be done if your NFS server supports it and is protected by a UPS as the caching provides the potential for file corruption in the case of catastrophic failure.

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's group and for other users. You can change these permissions from the control panel NFS client applet.

Filename mapping

You can map how both new file names are created and existing filenames are mapped between the remote NFS server and your SFU NFS client. The mappings can preserve case or automatically convert to either all lower case or all upper case. Additionally, you can opt to have existing filenames matched by ignoring the case.

Tip In a mixed environment where users will be accessing files from both Windows NT and UNIX, you'll find that setting filename mapping to automatically convert to lower case, but match by ignoring case will provide the least disruption to both communities of users

Configuring NFS LANs

You can configure your NFS LAN by creating a FavoriteLAN or by creating one or more broadcast LANs. Use broadcast LANs to divide up your network into logical segments to limit the broadcasts to only a specific portions of your network and cut down network traffic. You can also create a single FavoriteLAN that has the NFS servers you most frequently connect to. These servers are entered in by name or IP address, regardless of what segment they are on. By using a FavoriteLAN you limit the amount of network broadcast traffic and speed up connecting to your preferred resources.

Symbolic links

Symbolic links are a way for a file or directory to exist in one physical location, but be seen as existing in another location or locations. When a symbolic link references a file or directory that is local to the machine where the link is located, Client for NFS doesn't need to do any special manipulation to follow the link. But symbolic links can also be created on an NFS server that point to files or directories that actually reside on a remote machine. In order to resolve these links, Client for NFS needs to have a mapping file that identifies the actual machine that the link points to. This mapping file can reside on the local client machine or can be located centrally on the network for easier administration. The mapping file is an ASCII text file and has the format:

# Lines beginning with a # sign are comments and ignored

mnt \machine\export

Caution should be used with symbolic links. By default, Client for NFS does not resolve or display unresolved links. It will also not allow rename or delete on a symbolic link. You should only enable rename or delete of symbolic links if you fully understand the consequences and know what mechanism or program will be doing the renaming or deleting. A symbolic link that is deleted and then replaced with a file of the same name is no longer a symbolic link. In this scenario there will be two files on the NFS serverthe original file in its original location, and the replacement file, in the link location.

Connecting to an NFS Export

Connecting to an NFS export can be done in a variety of ways, using either standard Windows syntax (\\server\share) or standard UNIX syntax (server:/share). You can browse using the Explorer, or use the command line net commands. For example, from the command line, either of the following are acceptable and equivalent. However, the first, using standard UNIX syntax, will be somewhat faster since it immediately resolves to the native NFS syntax and bypasses the need to look for a conventional Windows share of the same name.

net use * server1:/home

net use * \\server1\home

Tip Use the provided Show Mounts application to quickly query a particular server for the exported filesystems.

NFS Server

Services for UNIX provides a robust NFS server that can be used to provide disk resources from your Windows NT-based machines to any machine on your network that supports NFS.

Shares

Shares are created using the Server for NFS control panel applet, or by selecting the NFS Sharing tab from the Properties page using Explorer. You can share either individual directories or entire drives. Drive letters in the form D: are converted to the syntax /D/. So the share of your F:\UserHome directory would be visible to NFS clients on the network as: /F/UserHome. You can also give shares an alias if you want, though adding an alias will require a reboot of the server before the alias will be effective.

Tip Using aliases for NFS shares (exports) makes life easier for users, hiding the sometimes awkward complexities of exactly where the share is located. Since creating or changing an alias requires a reboot, you should plan your deployment to create as many aliases as possible at once, reducing the resultant reboot time.

Client Groups

Server for NFS provides a mechanism for managing permissions and shares by groups of computers, known as Client Groups. By creating client groups you can export (share) filesystem resources to specific groups of computers without having to specify each individual computer each time. This also improves management and administration by letting you manage the groups members from one location. By changing membership in the group, you change which computers have access to any resource that references that group, making for simplified administration and management.

File Locking

File locking can be enabled for NFS clients, and these locks can be enabled on a system wide basis, being propagated both locally and across the network.

Security

Server for NFS uses Access Control Entries to simulate the permissions that are typical in the UNIX and NFS world. You can, however, inhibit certain permissions behaviors that are normally possible in the UNIX permission set, but not generally done in Windows NT. Specifically, you can inhibit the ability to deny access to the owner and group of a file by an NFS client. You can also set permissions for objects to more closely match the way Windows NT manages them by setting implicit permissions on and giving Full Control by group and world.

Caution: It is important to understand that there are inherently different permissions sets in the UNIX and Windows NT security models and that any attempt to align them is merely an approximation. UNIX users can only actively have the permissions of a single group at one time, making the permissions essentially single threaded. Windows NT users, on the other hand, may belong to multiple groups and garner their permissions from all of those groups collectively.

Connectivity

Microsoft Windows NT Services for UNIX provides several tools to improve connectivity between Windows NT- and UNIX-based machines, including a mechanism for synchronizing passwords and full telnet support.

Password Synchronization

Password synchronization is a one way synchronization utility that allows you to manage both your UNIX and Windows NT passwords from Windows NT. Services for UNIX comes with precompiled Password Synchronization Daemons (SSOD) for HP-UX, Sun OS and Digital UNIX, along with source code to permit compiling on other versions of UNIX.

Two options are supporteduse of a secure daemon (SSOD) to accept encrypted passwords from Windows NT, and an unencrypted, non-secure method using rlogin to pass the new password via clear text. Obviously, the use of rlogin has inherent security concerns, but it is relatively easy to set up and may be perfectly sufficient in a smaller network that is adequately secured from external influences. It also requires no additional software or configuration and is essentially platform independent.

Creating And Configuring A UNIX Pod

UNIX hosts are organized into pods, with the password synchronization method being managed on a per pod basis. You can create a new pod, add a host to an existing pod or change the synchronization method for a pod using the Password Synch Administrator (psadmin.exe).

When you create a new pod you are prompted for the member hosts of the pod, and the password synchronization methodology that will be used for the pod. You can change this later. You also have an option to turn on verbose loggingby default, only failures are logged, but with verbose logging enabled all synchronization actions are logged to the Event Viewer.

Using rlogin to Synchronize Passwords

While many UNIX environments will not permit the use of rlogin, because of the inherent security issues with it, in many smaller, mixed UNIX and Windows NT-based environments it provides a simple and easily configured mechanism. Especially where the network is completely isolated from the outside world by a highly secure firewall (or no connection to the outside world at all) and the primary concern internally is for simplicity and ease of administrationthe case in many small businesses where there may well not be a dedicated system administrator. If this is the case in your environment, you can use rlogin to manage the synchronization between your Windows NT- and UNIX-based machines. This requires no specialized daemon to be running on the UNIX host, nor is this method restricted to only those platforms for which a pre-compiled daemon exists.

To set up an rlogin password synchronization, you need to configure the remote UNIX hosts to correctly support rlogin. This requires configuring a remote .rhosts file on the server. The .rhosts file must have permissions such that only root (or the account authorized to change passwords) can write to the file, and it must be owned by root (or that alternate account) and reside in the home directory of the root or alternate account. (This will generally be the / directory for the root account.) It should contain a listing for the machine where the password change will be made (in most cases the primary domain controller if you're running in a domain environment.) This listing should have only the short name for the machine, not the fully qualified domain name.

The default configuration for rlogin synchronization uses the root account, expects a prompt of "#" and that the password changing command is "passwd". If your environment is different than this, you can modify these defaults using the Password Synch Administrator.

Keep in mind that, unlike Windows NT, UNIX accounts are case sensitive. You'll want to make sure you create accounts on the Windows NT side that are the same case as the UNIX accounts, usually lower case only. Failure to do this will cause the password synchronization to fail.

Tip If your Windows NT accounts are already created, using mixed case, but you want to take advantage of password synchronization to align your Windows NT and UNIX accounts, you can rename the Windows NT account to all lower case without causing any inconvenience for your users. Their login and account permissions will be unchanged, but you will now be able to synchronize them with the identical, lower case, account on the UNIX server.

Using Secure Password Synchronization

Services for UNIX provides for secure password synchronization using pre-compiled binaries that run as daemons on the UNIX server, allowing the UNIX server to receive encrypted passwords sent by Windows NT and then modify the UNIX password for the same account. There is also source code available on the Windows NT Services for UNIX CD-ROM that makes it possible to compile on other platforms in addition to the three provided (Sun OS, HP-UX, and Digital UNIX).

Installing the Password Synchronization Daemon on UNIX

If you have installed the NFS client on your Windows NT-based source machine, export the target filesystem from the target UNIX machine and mount it on the Windows NT-based machine and use Explorer to copy the SSOD and ssod.config files to the UNIX machine. A typical target location is: /usr/local/etc, but this will vary from system to system and is not critical. If you use File Transfer Protocol (FTP) to copy the files, make sure you use a binary transfer to prevent corruption of the files.

Once the files have been copied to the UNIX machine, use the appropriate mechanism to install themthis will vary depending on your platform, but can include pkgadd or other installation mechanisms. You'll also need to edit the ssod.config file to reflect both the locations of files on your system and the type of synchronization appropriate. The file supports both NIS and /etc/passwd as security mechanisms, and when using /etc/passwd you can also select to use a shadow file (/etc/shadow) on systems that use password shadowing.

The ssod.config must reside in the same directory as the daemon. Once configured, you can start the daemon manually or add it to the appropriate startup file. Startup mechanisms vary from platform to platform, but can include /etc/rc.local and shell wrappers in an /etc/rc2.d directory.

When you create the UNIX pod and select Use Encryption, you'll get a Secure Propagation Settings dialog box. Here you'll enter the port number you've configured on the UNIX side. Enter the secret encryption key that you chose in the ssod.config file. This key will be used to triple-DES encrypt the password before it is passed over the network.

Note: All hosts in a UNIX pod must use the same encryption key. However, different pods can use different keys.

Telnet Server

Telnet is a protocol used by a wide variety of devices and operating systems to provide a command line interface to the device or system remotely. It is frequently a least common denominator to provide remote administration between systems. The SFU telnet server has several features specific to Windows NT that can be configured using the provided command line administration utility, tlntadmn.exe.

Configuring the Telnet Server

As installed, the telnet server works optimally for most installations. It will accept logins from a variety of clients, including the graphical telnet client shipped with Windows NT and Windows 95/98 and a variety of character mode terminal clients from virtually any operating system. Additionally, it can be configured to meet specific site requirements to improve security, simplify logins, and so forth.

NTLM

The SFU telnet server supports Windows NT Lan Manager (NTLM) for authentication of client logins. Using NTLM allows users to be automatically authenticated to the telnet server based on their Windows NT login. This makes using telnet completely transparent to users, while ensuring that clear text passwords don't pass over the network. NTLM must be supported on the client side of the login as well, however. This means that UNIX clients will generally not support NTLM.

When using NTLM login, users are restricted to local drives on the machine they are logged in 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 using the tlntadmn program. This program provides a simple menu that will run from virtually any character mode window, including a remote telnet login. You can:

List the current users
Terminate a user or users
Display (and modify) the registry settings for the server
Start and stop the service

The registry settings you can change include:

To allow or disallow logins from a trusted domainthe default is on
The default mapping that simulates the Alt key from a telnet session
The default login domaininitially set to ".", by changing this you can make it easier for users to login. Set this to your normal Windows NT domain name, and the system will not require a login of the DOMAIN\username format, but accept a simple username.
The default shellthis is the command shell that the user will receive when they log in. By default it is %SystemRoot%\system32\cmd.exe /q /k. Generally, though, especially in a diverse environment, it is recommended to leave this value alone and let the user create a subshell if they have a preference.
The login script that is executed when the user logs in. The default value is C:\SFU\Telnet\login.cmd. Use this script to customize the settings for your users and make any drive mappings that needs to be made automatically. Keep in mind that the users Windows NT Login Script will not automatically execute for telnet sessions.
The maximum number of connections allowed to the server. Default (and maximum) is 63 if it is installed on Windows NT Server and 1 if installed on Windows NT Workstation. However, the actual number of connections to Windows NT Server may be less depending on the number of Windows NT client access licenses you have available (see SFU Microsoft Software License Terms for more details).
The maximum number of failed logins permitted before the session returns a failure. The default is three.

Whether NTLM is used for authentication. The allowable values are:
- 0no NTLM is used.
- 1NTLM is used if available, else a login prompt is presented. (This is the default setting.)
- 2NTLM only is permitted. No login prompt is presented.
  
  The use of NTLM only in a mixed UNIX- and Windows NT-based environment would effectively lock out UNIX users from the Windows NT-based servers, since they would not have a client that supports NTLM authentication. Using NTLM, however, prevents the passing of clear text passwords over the network.
The default TCP/IP port number used for telnet. The default is 23.

Registry Settings

You can use the provided telnet administration program to edit the registry settings for the telnet server, or you can edit them manually yourself using regedit or regedt32. The subkey for the telnet server is:

HKEY_LOCAL_MACHINE \SOFTWARE \MICROSOFT \TelnetServer \1.0

The keys and their types, which correspond to the tlntadmn settings given above are:

Registry Key	Type	Default Value
AllowTrustedDomain	REG_DWORD	0x00000000
AltKeyMapping	REG_EXPAND_SZ
DefaultDomain	REG_EXPAND_SZ	.
DefaultShell	REG_EXPAND_SZ	%SystemRoot%\system32\cmd.exe /q /k
LoginScript	REG_EXPAND_SZ	%SystemRoot%\system32\login.cmd
MaxConnections	REG_DWORD	0x0000003f (63)
MaxFailedLogins	REG_DWORD	0x00000003
NTLM	REG_DWORD	0x00000002 (NTLM only)
TelnetPort	REG_DWORD	0x00000023
Termcap	REG_DWORD	%SystemRoot%\system32\termcap

Telnet Server Registry Settings

Additionally, there is a specific subkey for performance tuning:

HKEY_LOCAL_MACHINE \SOFTWARE \MICROSOFT \TelnetServer \1.0\Performance\NumThreadsPerProcessor

The minimum value for this setting is 2 and the default is 10 (0x0000000a). For most environments, the default value will optimize performance.

Warning: Use extreme caution when editing the registry. Editing the registry can result in a computer that won't boot, so backup your registry before making any changes.

Telnet Client

Services for UNIX provides a character mode telnet client that is both faster and better behaved than the default graphical mode client. It has additional emulations and supports NTLM authentication to speed up logon to Windows NT-based systems running the SFU Telnet Server.

The new character mode telnet client provides for greatly improved terminal emulations including an ANSI emulation that supports colors correctly when connecting to servers that support it, such as SCO. There is also a new VTNT emulation that supports enhanced features when connecting between Windows NT-based machinesincluding the ability to run complex character mode applications such as edit.exe that won't work with standard terminal emulations.

Configuring the Telnet client

The character mode telnet client replaces your original Windows NT graphical telnet client, which is renamed to telnetw.exe should you have a need or desire to run it. The telnet configuration is done from within a telnet session by escaping to the telnet prompt. Press ^] (that's Control-right bracket) to bring up the telnet prompt once you've started a telnet session. From here you can type:

?to get help
closeto close the current connection
displayto show the current operating parameters
pen <machinename>to open a connection to a machine (you can use an IP address here as well)
quitto exit the telnet client completely

setto set an operating parameter
- set ?get help on other set options
- set NTLMturn on NTLM authentication
- set LOCAL_ECHO
- set term <value>set the requested terminal emulation. Choices are: ANSI, VT52, VT100, VTNT
statusprint the current status
unsetto unset the options set with the set command.

Tip if you use the telnet client to primarily connect to UNIX systems, set term to ANSI and NTLM off, but if you frequently connect to both Windows NT- and UNIX-based systems, or primarily to Windows NT-based systems, you'll find the VTNT emulation a better preferred choice and you'll still fall back to ANSI when connecting to a system that doesn't support VTNT.

UNIX Utilities

Services for UNIX includes a limited subset of the MKS (Mortice Kern Systems) ToolKit. It does not attempt to provide an actual UNIX or Posix command line, as some others do, but provide a UNIX work-alike environment. It is actually more flexible and natural for those who go back and forth between both UNIX and Windows NT-based systems than a more purist Posix subsystem and shell.

The included utilities and Korn shell provide the basic UNIX work-alike environment, but if your favorite utility is not included you can add the full MKS ToolKit as an add-on to get the missing pieces.

The Shell

The core of the UNIX Utilities is the shell. The MKS version of the Korn shell is a full featured, Posix compliant, implementation that supports Korn shell (ksh) extensions such as [[]] compares.

KornShell

The Korn shell (sh.exe) as implemented in Services for UNIX is case-insensitive (but case-preserving on NTFS filesystems) for filenames and directories, and supports drive letters as filesystem mount points rather than a single root filesystem to which everything else mounts. So, for example, to change to the root directory of the D: drive, one would use:

$ cd d:/

where the $ is the shell prompt (PS1). However, the Korn shell also supports using backslashes, but they must be either quoted or escaped. So using this method one would change to the root directory of the D: drive with:

$ cd d:\\

or, by quoting:

$ cd "d:\"

Windows NT doesn't have an equivalent concept to a single, root directory with mounted filesystems. Each filesystem is identified by a drive lettera letter, either upper or lower case, followed by a colonand is a standalone filesystem without an overall root filesystem and directory on which the various drives are mounted. So a cd / will take you to the root of the current drive letter, but not to the overall root. To change between drive letters, you use the syntax:

$ cd c:

to change to the C: drive, usually the first hard drive in a Windows NT-based machine. You can, of course, alias this command to behave like an Windows NT user would expect:

alias c:='cd c:'

Start Up Files

UNIX Korn Shell implementations use two files stored in the user's home directory to customize the environment for an individual user.profile and .kshrc. The first file, dot-profile, is read every time the user logs in and whenever the user opens a new window and explicitly asks that it be read (by means of a login shell command line option.) In Services for UNIX, the equivalent file is profile.ksh and it should be stored in the user's home directory as well.

The second of the environment filesdot-k-s-h-r-cis read whenever a process opens a subshell, even when there isn't actually any window being opened. As such, it's a perfect place to add environmental settings that need to be available to every shell, regardless. The equivalent file in Services for UNIX is environ.ksh. However, by default this file will NOT be used unless you explicitly add a command to the profile.ksh file:

ENV=$HOME/environ.ksh

export ENV

As shown, each user will get their own environment file. However, you may want to create a main environment file, stored centrally, that sets some basic default environment files and then use that file to call the user's custom version by sourcing the user's environ.ksh file:

. $HOME/environ.ksh

UNIX users will recognize this syntax, but for Windows NT users who are new to the Korn shell, this is the equivalent of calling a batch file. The changes made in the external file are propagated into the calling environment.

Metacharacters

Metacharacters are characters that have special meanings in a particular context. An example is the asterisk (*) character at the MS-DOS or Windows NT command line, which can substitute for zero or more characters. The Services for UNIX Korn shell provides for a rich set of metacharactersfar richer than the normal Windows NT command shell. A good starting point is the UNIX Shell and Utilities Help included as part of SFU.

Command Line Editing

By default, Services for UNIX uses the standard Windows NT command line editing and recall conventions using the arrow keys on the keyboard to scroll through the recent commands. For most Windows NT users moving to the Korn shell for the first time, this will be a comfortable and convenient behavior. The SFU Korn shell supports both standard command line editing modes of the UNIX Korn shellvi mode and emacs mode. Emacs and vi are the two most common editors in the UNIX world and both have powerful features. If you are comfortable with either as a command line editor, you can enable them by adding the appropriate environment variable to your profile.ksh file:

EDITOR=vi #Substitute "emacs" for "vi" if you prefer

export EDITOR

Switching to this mode of command line editing will, however, disable the native Windows NT command line editing, so you will probably not want to include the command as part of a centralized, common environment file, but leave it for individual users to set.

Aliases

The SFU Korn shell provides for the ability to alias a command with a more familiar command. So, for example, if your users commonly go back and forth between UNIX and Windows NT, they're likely to want a default set of aliases to make standard Windows NT commands work from within their Korn shells. Additionally, most users will find they develop a personal set of aliases that are shortcuts for their own workthese should go in your environ.ksh file.

Here are a couple of aliases that you may find useful:

alias dir='ls oa' #closest ls version to the MS-DOS dir

alias ll='ls la' #full long listing
alias bdf='df kP' #disk space, the HP way
alias cls="'$SystemRoot\\system32\\cmd.exe' /c cls"

Another useful change you can make to your environ.ksh file will help you simulate the typical MS-DOS prompt which provides much more useful information than the seriously unhelpful SFU Korn shell $ prompt. The primary prompt in the Korn shell is known as "PS1", so to create a new PS1 that tells you where you are:

export PS1='$PWD'">$ "

Included Utilities

Services for UNIX includes a subset of the more common UNIX utilities. A comprehensive set of additional utilities are available as part of the MKS Toolkit Update Edition.

File / Directory Utilities

The included filesystem utilities are:

mkdircreates a directory. With the p switch, will creating missing directories if necessary to create the target directory.

mkdir [-p] [-m mode] directory ...
mvmoves files and directories. Can move entire directory structures with the R (recursive) switch.

mv [-R] [-fiv] source target
cpcopies files and directories. Can copy entire directory structures, preserving permissions, access times, and so forth. with the R (recursive) and p (preserve) switches.

cp [-R] [-cfimpv] source target
rmremoves (deletes) files and directories. With the r switch removes entire directory trees.

rm [-rifv] target[s]
rmdirremoves directories if they are empty. With the p option will remove directories all the way up the tree.

rmdir [-p] target[s]
lslists files and directories. Comes with a variety of possible switches to change the way the resulting listing is displayed. By default, lists only the filename in a multicolumn format.

ls [AabCcdFfgikLlmnopqRrstux1] [-X attr] [pathname...]
touchchanges various dates and times associated with a file or files. Will create the file if it doesn't exist unless the c option is present.

touch [-acm] [-f agefile] [-r agefile] [[-t] time] file ...
lncreates a link to a file or files. This creates another directory entry for the file that points to the exact same file. With the R (recursive) switch will link entire directory trees at once. Doesn't support symbolic links.

ln [-fiRrv] old new
findthe full UNIX find command. Finds files based on a variety of criteria and can then perform operations on those files. The default operation is print, to print out the found files in the specified directory hierarchy that meet the conditions in the expression[s]

find location expression[s] [operation]
teepipes a copy of the standard output of a program to one or more files. Standard output also gets the output.

tee [-a] file[s]

Text Utilities

The included text manipulation utilities are:

via full emulation of the standard UNIX file editing utility. Supports macros, abbreviations, regular expression matching, and ed commands. The default resource file is ex.rc in the users' home directory.

vi [-elRsvx] [-c command] [-t tag] [-w size] file[s]
wcword countcounts the number of words, bytes, characters or lines in a file or standard input.

wc [-c|-m] [-lw] file[s]
sortsorts and/or merges files or standard input according to a rich set of criteria.

sort [-cmu] [-o outfile] [-t character] [-y[n]] [-zn]

[-bdfiMnr] [-k start[,end]] ... [file[s]]
taildisplays the last n lines of a file (10 lines by default). With the f option, monitors a file as it grows, tailing it every 2 seconds.

tail [-f] [-b|c|k|l|m|n] [-number] [file]
headthe reverse of taildisplays the first n lines of a file (default is 10 lines).

head [-b|c|k|l|m|n] [-number] [file]
moredisplays a file page by page. Supports movement commands from the vi/ed editor. In the SFU implementation, more is bi-directional, supporting forward and backward movement through the file.

more [-ceiSs][-A|-u] [-n number] [-P prompt] [-p command]

[-t tag] [file[s]]
sedthe streams editor. A fast, flexible, inline editor. By default reads from standard input and writes to standard output. Supports multiple scripts on the same set of files.

sed [-En] script [file[s]]

set [-En] [-e script] ... [-f scriptfile] ... [file[s]]
catconcatenate. Displays or concatenates each file argument to the standard output.

cat [-su] [-v[et]] [file[s]]
grepget regular expression. The SFU implementation supports egrep (extended grep) and fgrep (fast grep) as well. Used to match a regular expression within a file or input stream.

[e|f]grep [-bcEFilnqsvx] [-e pattern] ... [-f patternfile] ...

[pattern]

Programming

Services for UNIX provides an excellent port of the Perl programming and scripting language, in addition to the Korn shell. Perl is a free, full featured, interpreted language ideally suited to administrative and web based tasks. The included version contains important additions to enable it to work more effectively in Windows NT, but doesn't contain all of the modules that have been written for Perl which are available from Comprehensive Perl Archive Network (CPAN, https://www.cpan.org ).

Security

The two security based programs included in SFU are:

chmodchange modechanges the access permissions of the specified files or directories. With the R (recursive) switch, changes all files and directories in the tree below the pathname as well.

chmod [-fR] mode pathname[s]
chownchange ownerchanges the owner (and, optionally the group) of the specified files or directories. With the R (recursive) switch, changes all files and directories in the tree below the pathname as well.

chown [-fR] owner[:group] pathname[s]

Use Scenarios

The addition of Windows NT Services for UNIX into a mixed Windows NT- and UNIX-based environment provides administrators of both Windows NT and UNIX with additional tools to manage their enterprise while giving users a seamless environment that lets them be more productive.

Central Password Administration

Services for UNIX's Password Synchronization gives the enterprise administrator a simple tool to manage passwords across the entire enterprise in a way that is transparent to the user. Once set up, the password synchronization daemon lets all passwords be managed by the domain controller. Changes to the user's Windows NT password are automatically propagated to the UNIX environment. This has the obvious advantage of letting the user remember a single password across all machines used. But it also gives the system administrator of both systems more credibility when attempting to enforce fairly strict password rules. The user may have to remember an arcane passwordbut only one across the entire enterprise.

Common File Systems

By using both NFS client and NFS server, the UNIX and Windows NT system administrators have the ability manage the overall enterprise disk resources in the most efficient manner for both transparency and cost effectiveness. Rather than have to maintain large disk farms for both Windows NT users and UNIX users, the administrators can combine the two intelligently, placing the resource where it will be most cost effective and reduce traffic at the same time.

An obvious commonality would be a central user home directory. By placing the user's home directories on a central Windows NT-based server, and then exporting the file system to the UNIX environment using NFS, the user has a single source for files regardless of the system they happen to be logged into. This not only makes the users more productive, it also reduces the overall storage requirements.

One company, a software developer of a large client/server application, has traditionally used a UNIX based version control product for maintaining its source code. The addition of SFU's NFS client allowed them to transition to a Windows-based front end to their version control software while the included UNIX utilities enabled the transition to be seamless for the configuration management engineers who maintained their familiar shell.

Central Backup

While large enterprises have access to large (and very expensive) backup tools that can backup both Windows NT- and UNIX-based systems using agents, these tools have generally been outside the resources of most small to mid-sized businesses. These have often ended up with a confusing mix of backup media and software that ultimately is both expensive and difficult to maintain. Services for UNIX lets this confusing mixture of backup programs and media be easily combined onto a single platform. By using NFS as a common filesystem, a single backup program and tape device can backup both Windows NT and UNIX filesystems without requiring proprietary (and often expensive) agents for each platform that needs to be supported.

Central Administration

Services for UNIX provides an excellent telnet client and server, giving the system administrator a viable command line administration environment. With the UNIX utilities Korn shell and Perl implementation, the administrator has a powerful set of tools that let a single administrator manage both Windows NT- and UNIX-based environments from a single desktop with a single interface. Scripts can be run on both Windows NT and UNIX that simplify common everyday tasks into a single script that is easily maintained.

Glossary of Filenames

psadmin.exe	The Password Synch Administrator
showmnt.exe	The Show Mounts application
showmount.exe	A command line show mount application
rpcadm.exe	The RPC information utility
rpcinfo.exe	A command line RPC information utility
dsreg.exe	NFS server configuration utility
dsurgp.exe	NFS server user and group configuration utility
tlntadmn.exe	The Telnet Daemon Administrator
telnetc.exe	The character mode telnet client
tlntsrv.exe	The Telnet server
scsetup.exe	Uninstall utility
sfuabout.exe	Version and license key information

For More Information

For the latest information on Windows NT Server, visit our World Wide Web site at https://www.microsoft.com/ntserver