CGI "Can't locate" error message

Posted by dorianw on 2017-04-14 09:24

I have a client who's CGI scripts are throwing this error:

Can't locate /defines.pli in @INC (@INC contains: C/Perl64/site/lib C:/Perl64/lib .) at E:\wwwroot\ELS_Application\cgi-bin\ElectronicLicensing\RE\RECertification.cgi line 29.

Any suggestion on how to debug this?

The server is running Win2012/IIS8/ActivePerl5.22. defines.pli is in the same folder as the calling script, RECertification.cgi in this case.

These CGI scripts are running fine on another server with same setup. They also ran for years on a Win2003 server running ActivePerl 5.8.

Could it be a problem with the installation of ActivePerl 5.22?

Here is a little more detail for Graham:

line 28: require "defines.pli";
line 29: require "$REQUIRE_DIR/defines.pli";

The problem is that $REQUIRE_DIR is null. $REQUIRE_DIR is defined in defines.pli on line 28. So it's not really reading line 28 either. I am not sure why it is not failing on line 28. If I put the full path instead of $REQUIRE_DIR, it works.

This same code has worked for years on a Win2003/Perl5.8.

thanks in advance
- Dorian

ActiveState Staff
Thu, 2017-04-20 10:36

Unfortunately, there are so many changes between Win2003/Perl5.8 and Win2012R2/Perl5.22 that "working in the past" provides no guarantee of any future success.

However, having the same setup working elsewhere is a lot more meaningful. This part suggests to me that you only need to look at areas that could be different between the working system and the failing system.

As far as ActivePerl goes, the only thing that might be different between the two systems would be how it was installed and who installed it.
- On the working system, ActivePerl might have been installed by a UserID with different permissions that the user that installed ActivePerl on the failing system. The new .exe installers should avoid most of this, unless the default userIDs have been tweaked by local policies.
- The target folder for ActivePerl might have different permissions on the working system than on the failing system, especially if the failing system used secondary or network drives as a target.
- IIS might have been shut down on the working system when ActivePerl was installed, and left running on the the failing system.
Those are just about the only possible points of difference.

It's a given that things will be very different between IIS 6 and IIS 8, and one of the key differences is that the "User" running the script will not be a real "User". "not really reading line 28" seems to be on the right track. Does the SYSTEM user have read/execute permissions on that folder where "defines.pli" is found? It doesn't seem to, and when it can't find the file the "require" falls back on @INC module loading which also fails to find the file, triggering the usual message. The working system may have added more sub-folders to the website setup than were added in the failing case.

'require "defines.pli"' is assuming that you have permissions in the CWD. and that the CWD will contain defines.pli. The way that CWD is determined is different between IIS6 and IIS8, since scripts that alter the CWD have the potential to become security holes. You could remove the assumption about CWD, and try providing the full path to defines.pli on line 28. I think that would have the same effect as it does in line 29, except that you might then be able to read a different value from the file for $REQUIRE_DIR".

dorianw | Fri, 2017-04-21 07:03

I think finding (or not finding) the Current Working Directory is the issue. If I provide a full path on line 28 it finds defines.pli and sets the variables such as $REQUIRE_DIR. Unfortunately, there are hundreds of cgi scripts, with hundreds of config files, on this server, so rewriting them all with absolute paths is not an option. For instance, there is a defines.pli at the root level and then in several levels of subfolders below root. All the files use relative path such as "../..". None of these are working because the application does not know what the CWD is. I assume that this is an IIS issue. We checked permissions and the web user and SYSTEM have read/execute from cgi-bin on down.

Thanks for your help with this. If you have any other advice please let us know.