Cheshire Cat Computing

I have a W2K3 box and upgraded routers.cgi from 2.14beta to 2.17 but unfortunately the middle section (graphs) of the screen does not appear when attempting to access them using a browser. The devices on the LHS and the targets on the RHS appear after I added
libadd = c:\mrtg\perl\site\lib into the routers2.conf file which I thought may have solved the issue looking a previous threads.

Also, when I click on the compact summary in targets, the follwoing error appears in the middle section.

Error
Cannot find RRDs.pm in c:\mrtg\perl\site\lib C:/Perl/lib C:/Perl/site/lib .


Any suggestions?

The problem is exactly as it says - the script is unable to find your RRD perl library (RRDs.pm and the associated files).

From the error message, you can see it is looking in the path: c:\mrtg\perl\site\lib C:/Perl/lib C:/Perl/site/lib

(in Perl, both forwards and backwards strokes can work as path separators). Is the RRDs.pm file in any of these? If not, then find where it is, and put that path in the libadd= directive in the routers2.conf (you can have more than one libadd= directive if you want to).

If the RRDs.pm file IS in this path, then it indicates that youhave the Perl RRD library installed incorrectly. You may have it installed in more than one location. Do a search on the C: drive for RRDs.pm and see if you have more than one instance - if so, you should probably delete one of them. You can tell which is correct because it should have an auto/RRDs/RRDs.dll in the same directory.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hi Steve,
The RRDs.pm file is in the c:\mrtg\perl\site\lib directory and the associated files \auto etc also exist. If I remove the libadd= directive from the routers2.conf file, I get the error constantly no matter what target is selected. But when added, the error only appears when the compact summary is selected (all other have the blank middle). This would indicate that it's finding the RRDs.pm file but not able to display the graphs.

I searched for a duplicate RRDs.pm file in the system but didn't find any. There are no errors in the log file, just the usual "MRTG started" lines.

If the others have a blank middle, then this would indicate that the script is actually crashing - which would usually only happen with an RRDs fault. Because removing the libadd directive causes the definite RRDs error messages, I guess its safe to say that it is finding the RRDs OK when it has the libadd. I can't see (in the code) why it should be able to catch an error if using the compact but not if using the standard graphs...

Can you take a look at your web server's error log? Are any more helpful error messages being printed in there?

Another possibility is that it is the IIS-CGI bug that is causing the problem (IIS has a bug in the way it handles the CGI interface). However I think you are using Apache (via the MRTG bundle) so it won't be that.

Sorry for all the problems...

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hi Steve,
I'm using the MRTG bundle.

When upgrading, does it matter where the "install from" directory containg the 2.17cgi details is located?

Is there any difference (in installation results) using the commands
"perl install.pl" or "install.pl" to upgrade the routers2?

Are there any services I need to start/stop after installation?

It doesnt matter where you unpack the install package to.

You can run the install.pl either using 'perl install.pl' or using 'install.pl' (provided you have the .pl association defined, which you do).

You may need to restart your web server after installing, since it probably uses mod_perl and will cache things.

Since the MRTG Bundle came out, the userbase has changed from being predominantly Linux to being predominantly Windows. I probably need to update the upgrading instructions for Windows and Bundle.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Hi Steve,
Found the problem. Its with the selection of the perl.exe file during
installation
Perl is : c:\mrtg\perl\bin\perl.exe
MRTG files : c:\mrtg\mrtg\bin\*.cfg
RRD files : c:\mrtg\wwwroot
Doc root : C:\mrtg\wwwroot
CGI bin : C:\mrtg\wwwroot
Config file : C:\mrtg\mrtg\bin\routers2.conf (already exists)
Routingtable: INACTIVE
Compact page: DISABLED
Caching : DISABLED
'usebigk' : mixed
Auth option : NONE


I was selecting the default in c:\perl\bin\perl.exe instead of that above.

Thanks
for your help

So - you have perl installed twice on your system, in two different places.

This means you also have two separate perl libraries, one used by each.

Probably, the RRD libraries are only correctly installed in the c:\mrtg\bin\perl and not in the other, resulting in the problem...

The install/upgrade script will search for perl, and it finds the c:\perl\bin one first, so it uses that as the default. It does sort of assume you only have one instance - and it also can't easily find the configuration of your previous install.

Thanks for posting the cause and fix. I'll see how simple it will be to check for more Perls on the system during an upgrade and pick the right one...

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11