AXS Visitor Tracking System v2.3.0.0025
Manual Install Instructions
Last modified on Friday, November 30, 2001.
This product has been designed for fast and easy installation. Follow these simple steps to get the script up and running in just a few minutes.
Download the product appropriate to your platform:
Each archive contains the exact same code, except that the Windows version uses "\r\n" line endings, and the Unix version uses "\n" endings.
The .tar.gz version can be decompressed with the command:
tar -fxz axs.2.3.0.0025.tar.gz
The .zip version can be decompressed with Winzip from www.winzip.com.
If you install a version other than 2.3.0.0025, follow the install file included with it, rather than this one.
Build Directory Structure
The script uses a specific directory structure to organize its libraries and data files. When the downloaded archives are expanded, they will automatically expand into the desired structure. You must retain that structure when transferring files between computers.
For your reference, Appendix II contains a detailed list of all files and folders, describing what they do and where they belong.
Note: this script uses relative paths extensively, and so its very demanding about its directory structure. It does not use absolute paths at all, however. That means you don't need to enter the absolute path into the script configuration files (if it needs to know its absolute path, it will auto-detect it).
In this step, you customize the CGI script files. Some library and data files also use the ".pl" extension, but those files must not be renamed or edited. The only files that you should edit are:
99% of this script is configured after the install is complete, using the admin control panel. Only two things need to be configured during installation:
Path to Perl
In 99% of cases, the default path to Perl of "/usr/bin/perl" will work and you won't need to edit the source code at all. In the remaining cases, you must edit the first line of each script file to point the appropriate path. Common alternate locations include "/usr/local/bin/perl" and "/usr/bin/perl5".
How do you know if you will need a custom path? Your web hosting provider should tell you. Or if you have existing Perl CGI scripts that work, you can copy the first line from them. Or if, after following all the instructions here, the script returns "Internal Server Error" when you visit it with a browser, the problem may be the path to Perl, and you may want to experiment with the alternate locations. Internal Server Error can mean a lot of things and the path to Perl is only one of them.
When you open the script file to edit the path to Perl, use the most hardcore text editor you have. Like, Wordpad on Windows, Simple Text on Mac, vi on Unix. Do not use high-level editors like Microsoft Word or HTML editors like FrontPage. There is a risk that these high-level editors will damage the code.
Perl CGI File Extension
In 99% of cases, the default CGI file extension of ".pl" will work and you won't need to change it. In the remaining cases, you must rename the CGI script files to use the appropriate file extension for your system. Some require ".cgi", and others require weird extensions like ".plx".
How do you know what extension is needed? Your web hosting provider should tell you. Or, if you have existing Perl CGI scripts that work, you can copy whatever extension they use. Or if, after following all other instructions listed here, your script returns its own source code when you visit it with a browser, or returns some other error, then the problem may be the extension. You may want to experiment with both ".pl" and ".cgi".
There are loose standards for these values - /usr/bin/perl and .pl - but not all web hosts adhere to them. This is not our fault. If your web host requires you to use /usr/foo/perl and the .cgi extension, please take this into account while reading program documentation that continues to make reference to /usr/bin/perl and "script.pl". Our docs are centralized and are not aware of what kind of strange values you've been forced to use. When our docs say "script.pl", and on your system you've been forced to use "script.cgi", then you need to treat "script.pl" as "script.cgi" while reading the document.
Unless you're doing all of your work on the web server itself, you must transfer the files and folders over to your web server. When transferring script files or data files in FTP, always use ASCII mode.
If your web server requires that CGI scripts be installed into a special folder, like "cgi-bin" or "cgi", then install all of the files to that folder.
The easiest way to set permissions is to run the "setperms" script appropriate for your platform. Run setperms.bat on Windows and setperms.sh on Unix.
If you have only FTP access to a Unix server, then you can set the permissions with FTP while you're transferring. Use the permissions guide in Appendix II below.
If you have a Windows web server without shell access, then typically you won't be able to run "setperms.bat" from the command line nor set permissions via FTP. In this case, the best approach is to try an install anyway (the server file system is often read/write/exec by default). If this doesn't work then contact the tech support people and ask them to run setperms.bat for you. If tech support can't help, you can use the Auto Installer process. It will attempt a few work-arounds to remotely set Windows file permissions. The methods don't always work so keep your tech support people as a backup.
CGI processes are usually executed under a user context different than your login account. Your login account owns the files and folders that store data. Because CGI processes are only allowed to write to files and folders which they own, or for which they've been given special permission, we take the extra step to make all data files and folders world-writable (any and all processes are allowed to write to them). That way, data can be saved by any user/process, and thus the script will work no matter how your CGI privileges have been configured.
Obviously, if your web server runs CGI processes under your login account context and not a separate context, then you may apply more restrictive permissions. Data folders can have permission 755 instead of 777; data files can have permission 744 instead of 766. If you are using CGI Wrap, or if you are installing to Hypermart.net or Netfirms.com, then this applies to you and you may use the more restrictive permissions.
Visit the URL "axs/ax-admin.pl" to get started.
(In this example we use the ".pl" file extension for Perl CGI scripts. As mentioned earlier, some web servers require the ".cgi" extension or some other. Use whatever file name you decided upon earlier in section 3 part 2.)
Please visit your admin page immediately. There is no username or password required by default, but you can configure them by opening the 'ax-admin.pl' script and entering values for $Username and $Password. Before any visits are logged, you must follow the instructions under "Instructions for Tagging HTML Pages", linked from the bottom of the admin page.
Manual Install Complete!
Appendix I: Error Handling
If you run into trouble, consider an automated install. The automatic install can self-heal from most common error conditions.
Free custom installs are available from the script author (as of Friday, November 30, 2001). To take advantage of this service, first attempt an automatic install. If it fails, you will have the option to forward an install request. Installs are usually finished within 24 hours.
You can also visit the Discussion Forum with a description of your problem. It stays very busy and there are many helpful people there.
The Auto-Installer is here: www.xav.com/cgi-sys/cgiwrap/xav/install.cgi
Appendix II: Directory Structure and File Descriptions
This file manifest applies to version 2.3.0.0025. If you are installing a different version, use the install.html file included with it.
The file permissions are modeled on the default Apache or Microsoft IIS permissions system, where a user account owns the files and a separate, unprivileged account, executes the CGI scripts. This is not the most secure configuration in the world, but it is the default that has been established, and so these file permissions follow it. If you have a system where your CGI scripts are executed under your user account context (as when using CGIWrap, when using setuid Perl, using Hypermart.net or many other free web hosts, etc.) then you can and should replace all permissions with 755/rwxr-xr-x.
|Is Required Object|
|Permissions||File / Folder||Description|
|Permissions||File / Folder||Description|
|Is Required Object|
Appendix III: Upgrade
To upgrade over a previous installation, without losing data, replace only these files:
Appendix IV: Uninstall
To remove the product, simply delete the folder that contains all the scripts and data files. The script does not effect anything outside of its folder.
Appendix V: Additional Resources
© 1997-2001 by Zoltan Milosevic