ello, everyone. I'd first like to thank Trevor for stepping in for me last month, as things were kind of busy for me, and the care and feeding of a new cable modem seemed to be right up the alley of a networking column.
This month, I'd like to discuss a few programs that are found in the \TCPIP\BIN directory of Warp 4 that, for this or that reason, haven't seemed to have received much publicity. However, for someone that is connected to the Internet most of the time (like Trevor and his pet cable modem), they can be extraordinarily useful. The first set of programs that we will be dealing with are a set of daemons that are, functionally at least, ports of common Unix programs.
FTP.EXE and FTPD.EXE are the text mode File Transfer Protocol program and the server daemon for File Transfer Protocol, respectively. For instance, if Trevor had a file on his PC that he wanted all of his writers to have, but didn't want to e-mail it out to everyone, he could stick it into a separate directory and configure and start FTPD. Then, when we need to access the file, we could just start a FTP session to his computer and retrieve it just like we would from one of the major OS/2 FTP sites.
FTPD also logs users, enabling us to keep track of who is using our system and who isn't:
[C:\]ftpd ********************************************** * IBM TCP/IP for OS/2 * * FTP Server (FTPD) * * Version: 22:16:09 on Jun 17 1996 * * (C) Copyright IBM Corp. (1991, 1996) * ********************************************** FTPDC: spawnned with socket 65 connection from 188.8.131.52 at Sun Nov 9 21:26:37 1997 FTP LOGIN FROM 184.108.40.206, brianj FTP LOGOFF from 220.127.116.11 at Sun Nov 9 21:27:05 1997 FTPDC: spawnned with socket 72 connection from 18.104.22.168 at Sun Nov 9 21:27:13 1997 FTP LOGIN FROM 22.214.171.124, brianj FTP LOGOFF from 126.96.36.199 at Sun Nov 9 21:27:43 1997
TELNET.EXE and TELNETD.EXE are, of course, the text mode Telnet and Telnet daemon programs. Using TELNETD, one can either remotely log in to one's own computer or allow others to do so. Unfortunately (in my opinion), TELNETD does not actually emulate BASH, TCSH, ASH or any of the other common Unix shells. It simply acts like a standard, command-line OS/2 shell, with one exception: When you install TCP/IP under Warp 4, it asks you for a host name (and defaults to MYHOSTNAME if a hostname isn't chosen). When you telnet to an OS/2 Warp 4 computer that is running TELNETD, you will see the hostname as part of the command prompt, like so:
Then, we have a whole host of printing/remote printing options. An LPR daemon can be set up with some effort on your local machine, which will allow both Unix and Win32 operating systems to print to your local host. The output from LPD when a print job is queued looks like this:
[C:\]lprd ************************************** * Line Printer Daemon (LPD) * * (C) Copyright IBM Corp. 1991, 1996 * * Version: 1.2.1 * ************************************** Print request from email@example.com for file foo.txt received. Print request from firstname.lastname@example.org for file foo.txt printing. Print request from email@example.com for file bar.txt received. Print request from firstname.lastname@example.org for file bar.txt printing.
In addition, one must have the LPRPORD.EXE set up and running like so:
[C:\]lprportd LPRPORTD Version 2.0.6 running (LPR Version 1.0). Servicing 8 printer pipes.
And, of course, one must actually print a file.
[C:\]lpr -s 127.0.0.1 foo.txt Trying LPD print server 127.0.0.1, device lpt1. printing foo.txt 5950 bytes. The entire document was sent.
In addition to lpr, there is a whole suite of Unix-style printer management tools, including lprmon, lprm, and lpq. While these utilities were (at least according to the literature) included primarily as a means of allowing Unix workstations to utilize services on an OS/2 system, there is nothing at all that prevents another OS/2 client from logging on and using these services as well.
However, ftpd, telnetd, and lprd all require some configuration before they will be usable. This is accomplished by the TCPCFG.EXE program. TCPCFG is actually a notebook that contains all of OS/2's network settings. The settings that affect the above programs are entered on the "Security" page. You can enter a telnet password that others can use to telnet into your machine (IMPORTANT NOTE: While the password is blacked out in the edit box in the notebook, it is stored in PLAIN TEXT in your config.sys (Hello, IBM: Was anybody thinking about security when this was implemented?). While, in a networked environment, your config.sys should be kept secure as a matter of course, this is an additional reason to ensure that you keep your box locked up both physically and remotely). You can also enter a list of users that may access your computer with FTP. Adding an FTP user is somewhat confusing, however. After entering a username and password, you must choose directories. The checkboxes with the bizarre explanations actually reverse permission bitmaps. When you enter a read directory in the first edit box, that will be the home directory for the user to log into when (s)he first logs in. Unless of course, you have the check box below the edit box checked. In that case, you will be saying that the use does NOT have permission to read that directory. The same for the write directory permissions.
Some of these settings require changes to your config.sys, so you will have to reboot before you can use them. The TCP/IP settings notebook will also complain about a lack of a primary LAN card if you are using SL/IP or PPP, and it will complain about the fact that you (most probably) do not have settings configured for SENDMAIL (which is a port of yet another Unix program that you don't need, but is handy to have on occasion). As far as I know, the only use for SENDMAIL on an OS/2 system is for those who still use Ultimail Lite (yes, all five of you). Ultimail Lite, in theory, uses SENDMAIL to send your mail from your home PC to the POP server belonging to your Internet Service Provider).
TRACERTE is a command that allows you to "trace the route" of a given packet from host A to host B. It will allow you to see the routes (and routers) involved, and, if you suspect a bottleneck at any given point, it will show you the bottleneck also. Consider the following:
[C:\]tracerte www.microsoft.com 0 * * 188.8.131.52 (184.108.40.206) 500 ms 1 pm2-mhk (220.127.116.11) 172 ms 156 ms 156 ms 2 cisco (18.104.22.168) 141 ms 157 ms 156 ms 3 tpk5-s0-5.gi.net (22.214.171.124) 141 ms 218 ms 157 ms 4 tpk1e0.gi.net (126.96.36.199) 172 ms 156 ms 156 ms 5 lnk-h500.gi.net (188.8.131.52) 265 ms 250 ms 250 ms 6 184.108.40.206 (220.127.116.11) 204 ms 219 ms 219 ms 7 sl-bb2-kc-F0/0.sprintlink.net (18.104.22.168) 235 ms 250 ms 250 ms 8 22.214.171.124 (126.96.36.199) 266 ms 219 ms 219 ms 9 188.8.131.52 (184.108.40.206) 266 ms 282 ms 250 ms 10 220.127.116.11 (18.104.22.168) 360 ms 532 ms 562 ms 11 * 22.214.171.124 (126.96.36.199) 313 ms 313 ms 12 sl-mic-3-h0-T3.sprintlink.net (188.8.131.52) 485 ms 250 ms 281 ms 13 184.108.40.206 (220.127.116.11) 266 ms 343 ms 313 ms
It appears that Microsoft was having a problem this evening, since you can see that step 0 and step 13 are the same. This means that my packet (and my trace) are going in circles. There are, of course, other things that it could mean.
Well, that is about it for this month. Next month, we'll look some at security of systems in general, and OS/2 as a networking client in particular.
Brian L. Juergensmeyer is a programmer at the VA hospital in Topeka, Kansas. He annoys his IS manager by trying get him to convert from NT/WfW 3.11 to Warp Connect/Warp Server.
|Copyright © 1997 - Falcon Networking||ISSN 1203-5696|