Please note that this is a supplement to the README file not a replacement. Due to demand, I am in the process of porting PushSite to Microsoft Windows. Although the previous PushSite would run on Windows it was not a very easy fit. As of version 2.5 there are a couple of programs which also need to be installed but this should be a relatively painless exercise. QUICK INSTALLATION INSTRUCTIONS ------------------------------- 1) check that you have the "ls", "touch" and "perl" programs installed on your machine and that they appear on the PATH variable 2) copy the file "pushsite" to a suitable location. (e.g. c:\windows\command) 3) create a shortcut to the perl interpreter which takes pushsite as its argument and the pushsite directory as its "Start in" directory 4) edit the file pushsite.conf.win32 in a text editor (e.g. WordPad) to tell pushsite where to push the files to (there's more details in the file) save it as "pushsite.conf", by default the program will look for this file in C:\etc\ 5) optionally sret the the first line of the script to reference your interpreter 6) run the program! MORE DETAILED INSTRUCTIONS ========================== My development platform runs Microsoft Windows 95, and has the cygwin environment installed to provide some of the support tools pushsite requires. Details are given below. PushSite itself is written in Perl - a (sort of) interpreted programming language. I am using a binary edition of the latter downloaded from http://people.netscape.com/richm/nsPerl/ You can get the source code to Perl, and links to other implementations and programs written in Perl from http://www.cpan.org Please note that versions of PushSite before 2.5 will also require the Perl POSIX module. The CygWin program are licenced as GPL (free). Perl is covered by a slightly different licence but is still free. The Cygwin DLL and gnu fileutils binary for the cygwin environment are available from: http://www.cygwin.com Because..... 1) I want to keep the codebase as similar as possible, if not the same 2) Microsoft Windows does not provide as easy an interface to sources of data as Perl (e.g. $thisbox=`hostname`) 3) I'm no great programming guru 4) I don't want to spend the rest of my life writing this package (unless someone wants to pay me to do so) ...there may be some facilities available to Unix/Linux users not available to MS Windows users. But hey...you should be used to that already ;) Installing on NT ---------------- The program should detect when it is running on a MS Windows platform (by reading the WINBOOTDIR environment variable). Under Unix/Linux/Posix the operating system can check first line of a file to determine which interpreter to use. Explorer/DOS/COMMAND.COM do not (AFAIK) support this. However if you are running the program from a Unix type shell (e.g. the cygwin version of bash, or crond) then you should change the very first line of the pushsite program to reference your Perl interpreter. This will allow you to run "pushsite ..." instead of "perl pushsite....". e.g. #!C:\\Progra~1\\nsPerl\\perl.exe Note that the "\" character has a special meaning to Perl and to Unix type shells therefore you may to tinker some if you are specifying a config file on the command line (by default the program will look for C:\\etc\\pushsite.conf, then pushsite.conf in the WINBOOTDIR). Currently, PushSite requires some standard Unix tools. These are ftp, ls, touch, and, of course Perl. I've already mentioned the latter. The command line ftp client (ftp.exe) which ships with Windows 95, Windows 98 and Windows NT 4 can be used as a direct replacement, although it should be noted that it always tells the calling program that it worked - i.e. PushSite may not detect as many errors using this program as compared to other implementations. In addition, it does not seem to support the "passive" command. The 'ls' program lists files, optionally recursing through directories. 'touch' sets/updates the timestamp on a file. While simply copying a file back to itself (via a temp name) would provide enough functionality to replace touch, PushSite is very fussy about the format of directory listings which it processes (this may even cause problems on some Unix implementations). The quickest way I could get around this was to install CygWin which provides much of the functionality of a POSIX environment. If you are having problems with PushSite on a proprietary Unix platform, try installing the Gnu file utils (remember to set a custom PATH so PushSite uses these programs instead of the supplied ones). The critical files you will need for MS-Win32 are cygwin1.dll - provides a common base fileutils - Gnu fileutils includes 'ls' and 'touch' So, make sure that all the relevant programs are in directories specified by your PATH variable, and be prepared to tinker with the construction of filenames. I've not thouroughly test all the command line switches. If you can keep as many of the directives in the config file, and try to avoid spaces in filenames / directory names / username / passwd etc it should run OK. Note that if your perl binary is not called perl.exe and/or is not on the PATH then the '-e' flag (used for testing config files) probably won't work. Please base your config files on the pushsite.conf.win32 file unless you have a complete POSIX environment installed. I'm not sure how the program will attempt to interpret 'home' directories on Microsoft's Windows OS's so I'd recommend only using a global config file or specifying different config files on the command line / in the shortcut. By default, the program looks for c:\etc\pushsite.conf to get its config directives. Also, I'm afraid that unless you already have a POSIX type 'mail' program you won't be able to send out alerts automatically. The Unix man page for PushSite follows; this details how to configure and use PushSite puhsite(1) Dial-up Networking pushsite(1) NAME pushsite - PERL script to upload website to server SYNOPSIS pushsite [ -f configfile ] [ -p passwd ] [ -u username ] [ -v | -vv ] [ -l logfile ] [ -s src_dir ] [ -h dest_host ] [ -d dest dir ] [ -m mailaddr ] pushsite -t [ -f configfile ] [ -u username ] [ -v | -vv ] [ -l logfile ] [ -s src_dir ] [ -h dest_host ] [ -d dest dir ] [ -m mailaddr ] pushsite -e [ -f configfile ] [ -v | -vv] DESCRIPTION This manual page describes the operation of the pushsite PERL script. The program will update a set of files on a server. Unlike conventional mirroring packages, it does so by pushing a copy of newer files to the server. The program has three modes of operation; Normal connect and update remote files. Test site if -t is specified then test local data files only. Do not connect. Test config file if -e is specified, then try to spot any errors in config file. Do not test data files. Do not con­ nect to remote system. Various options are specified in the config file (which may be edited by the user) or over-ridden by command line switches. It uses ftp to send the file to the server. CONFIG FILE This is an executable perl program which sets up various parameters. If no config file is specified on the command line, then the system checks for a file .pushsite.conf in the users home directory, and failing that pushsite.conf in /etc See the sample config file for details of its operation. The config file contains a superset of the parameters which can be specified on the command line. Where a parameter is specified differently in the config file and command line arguments, the program will use the value specified on the command line. DETAILS When files are uploaded, the integrity of the remote site is checked as folows: Remote mods If the remote file is newer than the last upload. Remote dels If the timestamp of the local file is older than the last upload. and the file is not found at the remote site. Other If the file sizes do not match. Note this requires that the local clock be in sync with the remote system. A 5 second `grace' period is permitted. This can be extended by setting the grace variable in the config file. Optionally, files whose names match pre-defined regular expressions can be checked for another regular expression. This feature was intended for use on web pages to check that there are no URLs referencing the host / path on which the site was developed (as opposed to the host / path on which it is to be deployed). OPTIONS (corresponding config file entries are shown in {curly brackets}) -p passwd Password for ftp to dest host. {password} -t Don't connect to the destination host - just see if new files are to be sent. The number of files, total size (kb rounded up) and src_dir are reported. There is no config file variable for this operation. If -v has been specified, then the files are listed. If -vv has been specified, and illegal word checking is enabled, then the files a specified pattern ( chkfiles in the script - default value *.htm* / *cgi* / *.pl* ) are checked for a second specified pattern ( trapstr in the script - default value the name of the local host). The very verbose option also causes the program to report the options it is using. -u user User name for ftp to remote host. {user} -v or -vv verbose or very verbose. In test mode, very verbose causes the options being used to be reported to STDOUT. {verbose = 1 / verbose = 2} -l logfile File to write any alerts too. This file is created from new each time. If $html is set in the config file, then this file will be in html. Otherwise it will be plain text. {logfile} -s src_dir The directory to copy files from. {dir} -h dest_host The host you want to copy files to. {www} -d dest_dir After establishing the ftp connection, the program will cd to this directory. If you want to load files to the default directory then set this to '.' {remotedir} -m mailto The mail address to which any alerts should be sent. If $html is set in the config file, then this is in html format. Otherwise it is plain text. {mailto} passive (no command line option) If this is set to "y" then transfers are done using passive FTP. This is some­ times required for crossing firewalls / NAT / masquerading boundaries. {passive} NOTES In test mode, the program prints nothing if there are no files to be sent. If you use pushsite from a shell script, it is therefore quite easy to check if files have been updated: if [ ~ -z `pushsite -t`]; then pushsite -p mypasswd fi KNOWN BUGS The only known bug is that the program has no way of know­ ing if the ftp connection to the remote system fails. SEE ALSO ftp(1), perl(1) Authors Colin McKinnon Linux 10 Jan 1999 1