Windows Server Support for Unix Protocols and Utilities


Windows operating systems now support many protocols and utilities that were originally created for the Unix Environment. The first that comes to mind, and perhaps the most important, is the TCP/IP protocol suite. This includes not just the TCP/IP protocols, but other associated protocols and utilities.

Many of the technologies that began in the Unix world have evolved into standards that have been implemented on other platforms over the years. For an example, see the lpr/lpd printing system and TCP/IP stream printing. Both of these started out on Unix platforms and are now supported not only by Windows, OpenVMS, and other operating systems, but also by printers from Hewlett-Packard (and most other major printer vendors) and print server appliances made by a number of other vendors. When adding Windows computers to a network that consists mainly of Unix or Linux servers, printing can be the least of a network administrator's worries. It's a simple matter to configure Windows Server operating systems to direct printer output to a Unix system that manages print queues. It's also a simple task to configure clients to use a printer that understands the lpr/lpd protocols or TCP/IP stream method. And, of course, you can also configure Windows 2000 Server and Windows Server 2003 to operate as a print server using these protocols.

If you need to learn more about printing protocols, such as lpr/lpd or TCP stream printing, refer to Chapter 40, "Network Printing Protocols."


Other technologies that were either first developed in or adopted by the Unix world, which Windows and Linux also support, include the following, among others:

  • The TCP/IP networking protocol suite, including the standard utilities and troubleshooting tools

  • BOOTP and the Dynamic Host Configuration Protocol (DHCP)

  • Support for the Network Information System (NIS), developed by Sun Microsystems, and adopted by many other Unix/Linux vendors (refer to Chapter 29, "Network Name Resolution")

  • The Domain Name System (DNS)

This chapter covers the protocols and utilities that these diverse operating systems have in common as well as tools that can be used to fill in the gaps in a multiprotocol environment.

TCP/IP

When Windows NT 3.5x was first brought to the market, the default network protocol was IPX/SPX. Basic TCP/IP protocols and utilities were there if you wanted to use them, but at that time Microsoft perceived its main competitor in the client/server market to be Novell's NetWare. When NT 4.0 was released, the default networking protocol had been changed to TCP/IP. Because the Internet had begun to take on a higher degree of importance during the time frame in which NT 4.0 was being marketed, this was a natural path for the operating system to take. TCP/IP is the network protocol suite that's used throughout the Internet to connect computers from a wide range of manufacturers running many different operating systems. For example, you can find TCP/IP on every Unix or Linux variant currently on the market as well on most every operating system from IBM, from OS/2 to mainframes, along with any other major operating system vendor. Of course, by the time Windows 2000 was released, TCP/IP had become the de facto standard networking protocol for all Microsoft products. It's included with Windows Server, the Windows client operating systems, Me and XP, as well as the client version for Windows NT and Windows 2000.

Note

Novell's Open Enterprise Server combines NetWare 6.5 and SUSE Linux Enterprise Server. This provides backward compatibility for existing customers who cannot at this time upgrade to a Linux-based version of NetWare, as well as offer new functionality to NetWare, because Linux is a fast-rising star in the operating system community.


In a network that consists of Unix servers, TCP/IP can be used by Windows clients to access resources on these servers. The most common method provided by the TCP/IP suite of applications for executing commands on another computer is Telnet. For exchanging files, use the FTP utility. Other applications, such as the SSH (Secure Shell) utilities, can be incorporated into the network to allow for additional security.

Telnet

Windows comes with a Telnet client. Although Windows XP does not come with a Telnet server application, you can add this functionality by installing Services for Unix (SFU version 3), which is discussed later in this chapter. SFU can be installed on Windows NT, 2000, 2003, and XP. So, for those who operate a small LAN, you can install a Telnet server on Windows XP Professional, along with many other Unix utilities and commands, for a small fee.

Windows XP, which has now been available for about five years, has gone through two major service packs and is now widely replacing older Windows 2000, Windows NT 4.0, and Windows 9x clients.

Tip

If you're considering an upgrade to Windows Server 2003, you might want to wait before jumping onto the bandwagon. When any new major version of an operating system is released, there are problems. This is inevitable due to the complexity of writing code for an operating system, much less performing extensive beta testing for a wide variety of applications. It's best to wait until at least the first service pack is released. It's also a good idea to subscribe to the many Windows/Unix/Linux newsgroups so that you can find out about features/bugs early adopters are experiencing.


Server versions of Windows NT, 2000, and 2003 do provide a Telnet service, but it isn't enabled by default. You must have the TCP/IP protocol networking components installed in order to use the server. This can be done during the system installation or by using the Components button in the Add/Remove Software Control Panel utility. To start the service on a Windows Server 2003 computer, use the following steps:

Note

The examples and figures in this chapter are based on Windows 2003. Windows 2000 might look a little different, but the steps described in the examples are pretty much the same.


1.

Click Start, All Programs, Administrative Tools, and then Services. A list of services available on the computer is displayed in the right pane.

2.

Scroll down in the right pane until you find the Telnet service.

3.

Right-click on the Telnet service and select Properties (or just double-click on the Telnet service).

4.

From the General properties tab (see Figure 55.1) you can select how you want to start the Telnet service. The drop-down menu labeled Startup Type enables you to select Automatic (start when the system is booted), Manual (start the service when you want to use it), or Disabled (to prevent the Telnet service from being used). In this example, the Automatic option has been selected.



Figure 55.1. You can choose how to start the Telnet service using the General tab.


If you've selected either Automatic or Manual to start the service, you must start the service by clicking on the Start button shown in Figure 55.1. If you have chosen the Manual option, then you can close the dialog box and then re-open it and start the service when you wish by using the Start button. If you've chosen the Automatic option, the service will automatically start the next time you reboot the server. Notice also that there are Stop/Pause and Resume buttons on this General tab. The Start and Stop buttons do exactly what they say: They stop and start the service. However, if you use the Pause button, administrators and members of the Server Operators group can still use the service and establish a Telnet connection with the server. This can be useful when you don't want ordinary users making Telnet connections to the machine while you're performing maintenance chores, for example. Use the Resume button to allow the service to continue servicing other users (provided you haven't stopped the service).

Also in Figure 55.1, you can see that there are several tabs, each of which is used for a different set of properties that you can configure for the service. Using the General tab, you can change the display name for the service and the description of the service.

Tip

If one or more of the options (start, stop, pause, and so on) appear grayed out (unavailable), it's because the current state of the Telnet server does not enable you to make the selection. For example, if the Telnet service has already been started, the Start button will not be available. Similarly, if the service is stopped, the Stop button will be grayed out and not available.


The Log On tab functions the same as for other services. You should be familiar with how services work on Windows Server before using this tab or the Recovery tab. For example, using the Log On tab, you can select the user account that the service is run under. The AUTHORITY\LocalService account is typical for the Telnet service as well as many other services for Windows Server 2003. For Windows 2000 Server, the LocalSystem account is generally used for running services. At the bottom of the Log On tab, you can choose a hardware profile for which the service can be enabled or disabled. Select the particular hardware profile you want to modify and use the Enable or Disable button.

The Recovery tab, shown in Figure 55.2, determines how the service will be restarted if the service fails for some reason.

Figure 55.2. You can use the Recovery tab to decide what actions to take if the Telnet service fails.


The options available on the Recovery tab are

  • First failure Your options are to take no action (leave the service unavailable), restart the service, run a program (one other than the Telnet service, for example), or restart the computer. Using the restart option, Windows Server 2003 will attempt to restart the service. Selecting the Restart the Service option can be used if you suspect that the service was stopped because of some other problem with the server, and if you've selected the automatic startup type for this service.

  • Subsequent failure The options here are the same as for the First Failure drop-down list. However, the option you choose here will be used for each failure that occurs after the first failure. This can be modified by setting a value for the next field.

  • Reset fail count after If you leave this value at the default of 0, after the second failure, the next failure will take the action specified in the First Failure field. Otherwise, you can set the number of days that the service must run successfully before the failure count is reset to the First Failure field. A higher number of days will cause the service to use the action set in the Subsequent Failure field for that number of days. After the number of days you specify, the First Failure option will be used.

  • Restart service after Use this field to set the number of minutes that the system will wait before attempting to restart the service. This value applies to both the First Failure and Subsequent Failure options, provided that you've selected the Restart the Service option.

  • Run Program If you've selected Run a Program for either the First or Subsequent Failure fields, you can enter a program or a script file that will be run after a failure. This can be useful if you want to write a script file that notifies you that the service has failed, for example. You can use the Browse button to select a program or script file to run or just fill in the field labeled Program.

  • Command line parameters Use this field to provide command-line parameters that will be passed to the program or script file, if you have chosen the Run Program option.

  • Append fail count to end of command line The number of failures can be passed to the program or script file using this field. For example, you might want the script file or program to know how many times the service has failed and take a different action based on this value.

The Restart Computer Options button enables you to specify the number of minutes after which the computer will restart, if you have chosen that option in the preceding fields. In Figure 55.3, you can see that you can also enter a message to display to users on the network who are using the Telnet service to inform them that the service is either not available or being restarted, depending on the options you selected on the Recovery tab. Use the Restart Computer Options button on the Recovery tab to display this dialog box.

Figure 55.3. Select the number of minutes after which the computer will be rebooted after the service fails, and enter a text message to send to users currently using the Telnet service.


The last tab, Dependencies, is used to list the other services that must be running before the Telnet service can be started. If one of these services fails, for example, the Telnet service itself can fail. And if there is a problem in restarting one of these services after the computer reboots (if you chose that option), the Telnet service will not restart. In this case, you should check the Event Viewer to determine the reason that a service that Telnet depends on isn't restarting. If the Telnet service fails because a dependent service fails, you might consider using a script file to check for and restart dependent services.

Managing on Windows 2000 Server Telnet Server

After you've started the Telnet server service on the Windows 2000 Server, you can manage the server by using the Telnet Server Administration utility found in the Administrative Tools folder. As you can see in Figure 55.4, the interface to the Windows 2000 Server service utility is simple. You have the options of listing connected users or terminating users and the ability to start or stop the service.

Figure 55.4. The standard Windows 2000 Telnet server uses a simple interface for management purposes.


Option number 3 enables you to view current default settings that are stored in the Registry for the server. This option can be used to allow trusted domains access to the server, provide a logon script, and set the number of log failures before a user is locked out. An important feature you can use is one that forces users to use the more secure Windows NT NTLM authentication instead of the typical clear-text username/password method that is found in many typical Telnet server implementations. This should definitely be used in an all-Windows environment. However, Unix clients do not, by default, support this authentication method.

Note

The default Telnet server that comes with Windows 2000 Server allows for a maximum of two simultaneous Telnet sessions. If you need to allow more users to establish Telnet connections to the server, you'll have to use the Telnet server provided by the Microsoft Services for Unix (SFU) package instead. SFU is discussed later in this chapter and supports as many as 63 client sessions.


There are excellent third-party Telnet servers you can use with Windows. If you intend to make heavy use of Telnet on your network, it's worth investigating these competing products to determine which Telnet server is right for your needs. Don't forget, however, to look first at the server that you can get from SFU. Because SFU is available for about $100and you can install the products on as many Windows computers in your LAN as you want, with no additional feethis more robust Telnet server (along with many other Unix-based utilities) is a bargain.

Telnet provides a character-cell terminal emulation that can be used to run applications that do not depend on the features provided by either the Windows GUI or its equivalent in the Unix world, the X Window System. For example, it's easy to telnet into a Unix system to perform system administration tasks using a command-line interface provided by a shell. Script files can be edited and run remotely by using a Telnet session. Telnet is pretty much the standard for many operating systems for remote administration on a command-line basis. You can telnet to many different systems, each using a different operating system, and execute commands that are specific to that system. For example, from a Windows or Unix/Linux computer, you can telnet to an OpenVMS server, another Windows server, as well as all the various flavors of Unix/Linux. After the Telnet session has been established, just remember to use the commands that are appropriate for the operating system of the host you've established a session with. Telnet is a powerful application for system/network administrators who manage computers in the network that use different operating systems. Telnet servers have been imbedded in the firmware of many devices other than computers. For example, most printers, print servers, switches, and so on can be accessed using Telnet. This capability usually presents you with a menu to perform tasks specific to that device.

However, not all Windows administrative utilities have a command-line counterpart. And even when they do, you often find that the command-line version doesn't provide the full capabilities that the GUI version does. The same, of course, applies to other operating systems. For example, although you can telnet to a Linux box from a Windows system, you might not be able to use all the system utilities offered in the KDE/Gnome and other X Window System GUI interfaces that can be used on Linux.

However, Telnet and FTP are perhaps the two most useful applications now available on most operating system platforms.

Managing Telnet on Windows Server 2003

When using the Windows 2000 Server Telnet server application, you saw that the Command Prompt was used with a menu to enable you to manage the Telnet server. For Windows Server 2003, a command-line interface is also used, but you'll have to specify the option you want to manage instead of using a menu. The basic command used for all of these options is the tlntadmn command. If you enter just the tlntadmn command at the Command Prompt, with no qualifiers, a display (see Figure 55.5) shows you the current configuration of the Telnet server.

Figure 55.5. Use the tlntadmn command with no command-line parameters to display the current configuration of the Telnet server.


The syntax for this command varies depending on the function you want to perform. In the following examples, brackets are used to indicate optional components. You can use one or more of the command-line options listed here. The basic functions are

tlntadmn [\\remoteserver] [start] [stop] [pause] [continue] [-u username -p password] [-s] [-k (sessionid | all)] [-m (sessionid | all) "message"] 


  • \\remoteserver Specifies another server that you want to administer instead of the local computer's Telnet server.

  • start/stop/pause/continue These options operate in the same manner as detailed previously when using the Administrative Tools Telnet service tool.

  • -u username and -p password These command-line parameters can be used to specify a username and password that's valid on the remote server. Note that the user account must be an administrator account or an account that's a member of the Server Operators group.

  • -s sessionid Use this parameter to list information about a session.

  • -k sessionid | all Kill a session or use all to kill all sessions.

  • -m sessionid | all "message" Send a message to a particular user (using the session ID) or to all users. Enclose the message in quotation marks.

There are other command-line options you can use in addition to these basic ones. Use the help function to see all the possible options you can use with the tlntadmn utility.

Figure 55.6 shows an example of using two of these commands. The first command (-s) lists the current session of a remote user who has used Telnet to connect to the server. The second command (-k sessionid) shows an example of how to use the session ID (under the column ID) to kill that connection. You can also see information about the session, such as the domain name of the initiator of the session, the username, the IP address, as well as the date/time that the session was established and the amount of idle time (time that no commands were being used by the remote user).

Figure 55.6. This is an example of using the -s and -k command-line options.


The File Transfer Protocol

Like the Telnet server, Windows NT/2000/2003/XP comes with an FTP client. For Windows NT 4.0 through Windows Server 2003, the FTP server is provided by installing Internet Information Services (IIS).

Chapter 25, "Basic TCP/IP Services and Applications," covers the actual mechanics of FTP in greater detail.


The FTP Client

The FTP client can be utilized easily from the Command Prompt and uses the standard syntax that's common to other FTP clients, with a few exceptions that you might not notice. For example, although many Unix/Linux servers require that you log in by using the command User <username>, the Windows version prompts you for the username after you issue the FTP command as well as the password for the account name you enter. This is a minor difference, but it's important to note that although FTP is defined by a set of RFCs, some vendors add their own features to make the utility simpler to use.

The FTP server for Windows NT through Windows Server 2003 is a component of IIS, which is included as part of the installation procedure for Windows 2000. For Windows NT, you can use the icon that appears on the desktop of a Windows NT Server to install IIS or, better yet, download the newest version from Microsoft. IIS has been enhanced many times since its first release. Windows 2000 Server users will find that IIS is included on the server installation CD, but again, check for a newer version at Microsoft's Web site. An important reason for this is that newer versions have fixed problems with previous ones. Of course, the reverse is also true in some cases. One problem is fixed by a newer version, but might introduce a new set of problems! In Figure 55.7, you can see an example of using the Windows 2000 FTP client.

Figure 55.7. The FTP client enables you to upload or download files from another server.


In this example, you can see that the command FTP is followed by the site you want to make a connection to. If the site is available only to authenticated users who have an account on the server, you have to enter a valid username and password for that server. Another method for logging into many sites is to use the username anonymous. The convention for using this login is to use your email address for the password prompt. After you've logged in to the FTP server, you can issue commands that are available on that server. For example, the commands ls and dir will usually produce a listing of files and directories for the main directory that's set up for your login type. When using Unix/Linux or Windows clients, you can use the CD command to change to another directory until you find the data that you need to use. Notice that for most implementations of FTP, you must use lowercase characters for the commands and use the exact lowercase or uppercase syntax for a particular file. You can then use commands such as the following:

  • get Use this command to retrieve a file from a remote server. For example, get filename.

  • put Use this command to send a file to a remote server. For example, put filename.

  • mget This command can be used with wildcards (such as * and ?) to retrieve multiple files that match the wildcards.

  • mput This command works like mget, but enables you to send multiple files to the FTP server using wildcards.

  • hash If you care to watch the progress of an operation such as sending or receiving a file, this command will print hash marks (#) to show you the progress of the operation.

  • binary/ascii These commands specify the type of file you want to receive or send. ASCII files consist of simple text files, whereas binary files are usually executable files (application files, word processing files, and so on).

  • prompt This command might not be available on all implementations of FTP. This command is generally used with the mget or mput commands. When using these commands with wildcards, you might be prompted to specify yes or no (Y/N) before sending a file. The prompt command eliminates these prompts and just downloads or uploads all files matching the file specification.

  • quit This command is used to exit the FTP client.

Tip

Wildcards are used by many operating systems to indicate that you're specifying certain characters that a filename must contain and at the same time specifying that other characters can be anything. The asterisk (*) wildcard means that any characters (and any number of characters) can be substituted for the filename. For example, using the filename of Yoko*.txt will retrieve (or send) any file that starts with Yoko, ends with .txt, and contains any number of characters between Yoko and the dot (.) delimiter.

Another wildcard, the question mark (?) can be used to specify a specific number of characters that can be used to match a get or put operation. For example, the filename secret???.txt means that the file must start with the text secret and be followed by just three characters and the filename extension .txt. Contrast this with the * wildcard which allows for any number of characters following those you specify.

Additionally, you can specify the * wildcard in a manner such as *.mpeg2 to send or receive any file that ends with the file extension of .mpeg2, no matter how many characters make up the first part of the filename. The same goes for using the ? wildcard, although it still specifies that only filenames that contain the same number of question marks will be sent or retrieved.





Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2006
Pages: 411

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net