Zoom - How to enable search word loggingThis page aims to help you with enabling Zoom's search word logging feature on your web server. Note that to do this, you will be required to change file permissions on your server. If you are unsure whether you can do this, please check with your web host first. In our example, we will assume that the search page is at: And that we will want to store the log file at: First, you will have to enable logging and specify the filename in the Indexer configuration window. Note that the filename specified will have to be a relative path based on the location of your search script.
Note that in the screenshot above, we have specified a log filename of "./logs/searchwords.log". The dot at the start indicates that it starts from the current directory (where the search script is), under a folder named "logs", and a file named "searchwords.log". With this configuration set, you can now index the site, and upload the files to your web server using your FTP client. The difference between a URL and a file name pathFor logging to work, the log file name in the configuration window must be a file path with a file name, but not a URL. It is easy to get confused between the two. For example, /usr/www/users/mysite/search/logs/searchwords.log [GOOD] ./logs/searchwords.log [GOOD] http://www.mysite/search/logs/searchwords.log [BAD] Setting permissions for logging (via FTP)If your site is on a local web server, and you do not need to use FTP, please go to here From your FTP client (FTP Voyager is shown in the screenshot below, but most other FTP programs have a similar feature), create a new folder named "logs". Right click on this folder, and select Properties. You should be able to allow "Write" and "Read" permission here. If you have multiple permission sets, enable the Write permission for "User". If you can enter a "Numeric value" or use the "CHMOD command", specify "755". On some servers, you may need to specify "777" and provide full access because your server is configured to run the search script under a different user. You should still be able to restrict it more tightly than full access, if you consult your web host or try a few other settings. Exactly what restrictions you can implement depends on the way your web host has setup the server. You should check if "755" works first, and if you get a "Permission denied" error, try again with it set to "777". Note that some Apache servers will NOT allow you to do this and your search page may fail with an "Internal Server Error". So always use "755" if possible.
Testing your search pageYou should now be able to open up the search page, and make a search. After your first search is made, a "searchwords.log" file will be created in your logs folder. You can download this file to see the results logged. If however, this file is not created, and you get the following error message at the bottom of your search page: Log filename
and path not found (...) Then this means you may have:
Check the above and try again. If you can not change your folder permissions via your FTP client, consult your web host as they may not allow you to change this yourself and require a support ticket. Notes for CGI users on ApacheSince most Apache installations do not allow for the retrieval of non-scripting/binary files from the "cgi-bin" folder, we recommend specifying a log file location outside of "cgi-bin". This allows you to access the log file over HTTP or using the Zoom "Statistics Report" tool. For example, if your search CGI is at: Then we recommend creating a logs folder outside of cgi-bin, to
store your file, and specifying the following as the log filename: Your log file will then be accessible over the web from the URL: Setting permissions for logging (on a local server)If your web server is hosted locally and you do not access it via FTP, then refer to the following on how to change folder permissions to enable logging. Note: The following refers to Windows/IIS specifically. Linux/Apache users would need to use the chmod command via FTP or telnet. First, you should create the "logs" folder under your web hosted directory containing the search files. For example, if your search files are at "C:\Inetpub\wwwroot\search\", then create the logs folder as, "C:\Inetpub\wwwroot\search\logs\". Open up the IIS Administration Window on the server computer. This can be accessed via "Control Panel" -> "Administrative Tools" -> "Internet Information Services". Locate the "logs" folder in this window, right click to "Properties" and check "Read" and "Write" here. Logging should now be working, refer back to here for information on how to test your search page. If logging still does not work, then you may have conflicting file permissions set in Windows (outside of IIS). To fix this, open up Windows Explorer and locate the "logs" folder. Right click on the folder and select "Properties" -> "Security". Find the username which IIS uses for anonymous access to the website as. This is typically "IUSR_<machinename>" where <machinename> is the name of the server (you can check the required username on your server by right clicking on the "logs" folder in the IIS Administration Window, select "Properties" -> "Directory Security" -> "Edit". It should be specified under "Anonymous access"). If this user is not listed, click "Add" and enter the name. Now select this user in the list, and check the box to allow "Write" permissions. Click OK and your search page should now be able to write to the log file. Configuring logging for the CGI version on a Windows Server 2003 machine with IIS 6.0There are a number of issues with setting up CGI applications to have write permission to web folders on Windows Server 2003 and IIS 6.0. This was due to the significant changes in security and access permissions which introduces a number of conflicting (and A confusing) settings with the other layers of security in the Windows file system and the existing IIS management system. Most notably, IIS 6.0 introduces the use of several built-in accounts for running applications. These accounts affect the permissions that normally apply to the CGI search, and changes the permission requirements. The default account is "Network Service" which is heavily restricted. The "LocalSystem" account has full access and should allow the CGI to write to the "logs" folder (assuming the abovementioned file system permissions have also been set). Another important difference is that the working directory for a CGI application now appears always be the root folder of the website. This is different to previous versions of IIS (and other web servers) which would normally be the same folder as where the CGI is located. Because of this, the above examples referring to a log path of "./logs/searchwords.log" now behaves differently. The easiest way to overcome all this would be to use an absolute file system path, eg. a log path of "C:\Inetpub\wwwroot\cgi\logs\searchwords.log" Yet another new security measure in IIS 6.0 is that it does not serve unknown MIME types by default. This means that if you try to access the "searchwords.log" file via HTTP (eg. if you enter "http://www.mysite.com/cgi/logs/searchwords.log" in your browser, or in the Zoom Statistics Reports tool), you may get a 404 (File not found) error. To fix this, you will need to add the ".log" extension to the MIME types list in the IIS Management Console. See this Microsoft knowledge base article for more information. Alternatively, you could simply rename the log file to use a different file extension (eg. "searchwords.txt" if ".txt" is permitted on your server) by changing the log filename in the Configuration -> Advanced window. You should then be able to access the log file from the browser or Statistics Reports tool by using a URL with "searchwords.txt" rather than "searchwords.log". Configuring logging permissions for the (Classic) ASP version on a Windows Server 2008 (with SP2), Vista, Server 2012, or later.Later versions of Windows Server and Vista have increasingly complicated security schemes involving application pool identities. More information from Microsoft can be found here. As described in the link above, the Classic ASP (.asp) script itself will be running under the user account "IIS AppPool\<Application Pool Name>". By default, this would be "IIS AppPool\DefaultAppPool" (note that this is what you type into the 'Object names' field of the 'Select Users or Group' window, and it resolves to "DefaultAppPool"). However, since the ASP script actually uses the ADODB object for efficient binary and random access to index files, we need to determine what user account your version of IIS executes this under, to determine which user account to give permission to. While this does not seem to be officially documented, we've found this to be the "IUSR" user account. NOTE that this is not the same as "IUSRS" or "IIS_IUSRS" Return to the Zoom Search Engine Support page |
