When I first started out on this project, I was intending to write a generalized EMX runtime installation script. As I proceeded into it though, with considerable discussion with Peter Skye, I concluded there were too many factors that people personalize to make a general installation script. As an example, I normally lxLite compress the DLL's and move them to my \os2\apps\dll directory from the zip disk where I uncompress them. Other people might not want to bother with the lxLiting, they may have a dedicated EMX directory structure on their boot partition, or some other solution. Disk space is cheap nowadays.

So instead, I present the tool I wrote to simply grab files off the net when you just have a basic network connection and no fancy download tools. My inspiration came in part from an article in POSSI's Extended Attributes (Dec. 2000/Jan 2001, pages 4-5) titled "Duck Tales: Download Scripts," by Webfoot the Duck and his pal Pete. The article is about using WGet in batch files which he leaves sprinkled through his directories. The batch files serve as a kind of ultimate backup and documentation resource - showing where the files in the directory came from with the ability to grab them again. This, I thought, was a pretty good idea.

Typically you might find use for my script to download WGet itself and other tools that might then be used to write download scripts for other utilities, tools and applications. It might be useful to keep this in a maintenance partition, or as a tool for bootstrapping all your favorite tools into a fresh install. It's simple enough that you might be able to just cut and paste it into a .cmd file if needed.

The basic idea came from a brief mention in REXX Tips and Tricks, version 3.20. Some research on the OS/2 UseNet groups turned up that this method of scripting FTP wasn't totally unknown elsewhere, but still struck me as obscure, useful and interesting.

Basically, the NETRC environment variable points to a file where FTP macros are stored, some automatically executing on contacting a particular host. (On some operating systems, the environment variable is bypassed, and a file '.NETRC', '.netrc', '_netrc' or such is used directly for FTP macros.) The script generates a file with instructions to go to the host and grab the file specified by a URL. Some provisions are made for future features, but you could incorporate this into a script of your own for personalized purposes.

It's time to take a look at my Poor Man's WGet script:

• pmwget.txt let's you view it
• pmwget.zip let's you download it

Unlike the real WGet tool, this script doesn't have a legion of features to control it. One point I had some problems with is that my Warp install's FTP doesn't have 'passive mode' FTP, which is needed to work with just about any currently available firewall. (Passive mode is also discussed in my article Lynx on OS/2, Part 2.) The firewall will stop any attempt by an FTP server working in 'active mode' to contact your client to open up a channel for data transfer. Unlike protocols like HTTP or Kermit, FTP uses separate TCP connections for passing commands and data, resulting in a general nightmare for firewall configuration.

I found the following steps worked with my Linux ipchains (2.2 Kernel) firewall, to carefully poke a few holes for carefully selected major sources of OS/2 software in the firewall. Analogous steps will probably work with other firewall technologies.

0. Make sure the 'ip_masq_ftp' module is activated by making sure it is listed in the '/etc/modules' file, so you can even use FTP from PC's connected to the net through your firewall.

1. In both the '/etc/hosts' file on the firewall machine and the '\tcpip\etc\hosts' or '\MPTN\ETC\hosts' on OS/2 machines behind the firewall, add some lines like: # To help warp FTP through the firewall: 128.123.3.50 hobbes.nmsu.edu Hobbes 131.159.72.23 ftp.leo.edu leo

   On the OS/2 machines, put a line like this (courtesy of Steven Levine) in the CONFIG.SYS file:

   SET USE_HOSTS_FIRST=1

   These steps will start bypassing of the usual lookup of hostnames for these particular servers, and use the IP addresses listed directly in the hosts files. The purpose of this is to prevent any DNS-spoofing. Admittedly this is a pretty paranoid concern, but if you are serious about security it is a justified step when poking holes in your firewall.

   One drawback of this step is that if the IP address for a host ever changes you might get 'host not found' errors trying to connect to the FTP sites. But then you know what to change if this ever happens. Online tools to determine IP addresses are available at http://www.csu.net/connect.html and various other web sites, if you can only ping and such locally. Another problem is that this might not work if the host name actually represents some kind of cluster of servers where you are dynamically given an IP of an individual server for your session.

2. Finally, add some lines like: ${IPCHAINS} -A input -i ${EXTERNAL_INTERFACE} -p tcp \ -s hobbes 20 \ -d ${IPADDR} ${UNPRIVPORTS} -j ACCEPT ${IPCHAINS} -A input -i ${EXTERNAL_INTERFACE} -p tcp \ -s leo 20 \ -d ${IPADDR} ${UNPRIVPORTS} -j ACCEPT towards the middle of your Linux firewall script(s), where (in bash shell variable notation): ${IPCHAINS} is the fully qualified file name the ipchains utility (typically '/sbin/ipchains') ${EXTERNAL_INTERFACE} would be ppp0 (PPP connection), eth0 (ethernet) etc. which connects you to the Internet. ${IPADDR} is your IP address. ${UNPRIVPORTS} is '1024:65535', the ports your firewall will receive the active mode FTP data connection from the server on.

These lines will allow only FTP active mode servers at the specified host addresses to open FTP data channels (the '20' port numbers in the above commands) to your OS/2 PC, behind the Linux firewall. There is some small chance these hosts might be compromised, but they are administrated by serious people and all in all you have reduced these dangers to a minimum.

Similar steps can be taken with other firewall technologies.

Anyway, this worked for me and hope that others can find the information useful. I find it fun to watch the FTP client download files under automated control.

Copyright 2002 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.