MRTG / GCC / SAM

[ISG]

I am currently in the process of transfering our MRTG monitoring tool from an NT Server to an HP-UX9000/785 running 10.20 and perl v4.0(!).

As I understand it, in order to install MRTG you need Perl, GCC / binutils, gd, libpng and zlib. Most of these libraries are available pre-compiled as .depots, but they will not install correctly.

I was recommended to download a quality pack (700QPK 10-20)to get the system up to some kind of patch level, but all this appears to have done is stopped SAM running correctly from the GUI as it now gives an internal error and exits whenever you try to run it.

Before SAM stopped running, it would not recognise .depots from the GUI, and swinstall had to be used from the command line. gd installed with no problems like this using

swinstall -s /.depot /.depot

but several of the other depots are reporting IO errors or that the host cannot be contacted etc.

What can I do to get SAM working again and to install depots?


Also I have tried downloading source files for the above and compiling them, but this has been very patchy, with some software correctly installed and some not working at all. How do I uninstall / remove bad software which was installed using ./configure, make etc...?

Is anyone aware of a depot for MRTG containing pre-compiled libraries for all for all of the dependencies?

[Carsten Krege]

This is now guessing only, but I had this several times..
It might be possible that the depots that fail with I/O errors are invalid SD depots, meaning that they have a different format.

If you have a depot file you can easily test, whether it is valid by runnning "

# tar tvf my.depot

on it. SD depots are really tar archives!

What I think what could have happened is that the depots you have, have been gzip'ed or compressed for file transfer. In this case you can try the following:

# mv my.depot my.depot.gz
# gunzip my.depot.gz

or

# mv my.depot my.depot.Z
# uncompress my.depot.Z

And then use swinstall to install them.

It's a guess only, but I also wasted my time on those problems before..

Carsten

[Steffi Jones_1]

Hello,

I agree with Carsten...

Did you ftp the depots from one box to the other?

I have seen I/O errors on depots when the depots were ftp'd.

Check if Carsten's suggestion of tar xvf depotfile gives you an error. Then you know for sure, that the depot is corrupt.

Good luck,

Steffi Jones

[Philip Chan_1]

Hi,

I just installed mrtg today in both ways, depots and source compiling.

Depots, you can find mrtg depot file and all its dependency at

mrtg -> http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/mrtg-2.8.12/

Dependency depots are

jpeg-6b/
zlib
xpm
libpng
jpeg -> http://hpux.cs.utah.edu/hppd/hpux/X11/Graphics/gd
freetype

Be careful that the jpeg depot is not listed as a dependency but in fact it is.

Just download all these depots then do swinstall on them one by one in the above orders.

I also tried downloading the source for compiling. Just read the installation guide below carefully then you should be okay,

http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/unix-guide.html

The only thing that missing is the mentioning of jpeg-6 library, which gd depends on it.

Good luck.

Rgds,
Philip

[Printaporn_1]

Hi,

Normally when sam is not working latested sam patch always help.

[melvyn burnard]

One thing may be worth checking and that is the current state of the filesets on the system.
If you do the following:
swlist -l fileset -a state | grep -e install -e transient -e corrupt

Do you get any filesets reported back with one of these states?

If there are some in installed state, do:
swconfig \*

and then retry the SAM job

HTH

[ISG]

All,

Thanks for the tar xvf check, it turns out that several of the depot files were damaged. Would that explain why SAMs software manager couldn't see them?

Is there anything I can do to check why SAM is not working correctly?

Phillip,

thanks for the tips. I had downloaded the source code version of MRTG but would prefer to go with a pre-built depot for consistency. I am supprised that the Jpeg support is necessary as MRTG should us PNGs. Is it necessary to download GCC or will the libraries mentioned work with the HP Compiler? I mention this as the Unix readme mentions problems with the HP-UX compiler and recommends GCC.

Also do you know whether an updated version of perl needs to be used as this box is running V4 with the last patch from 1993!

Many thanks

Tim Haynes

[Philip Chan_1]

Tim,

I would suggest to use gcc for the compilation. In my case mrtg source compiled smoothly on with it. You can download Perl 5.6, gcc and all its dependent depots from the same place as stated in my previous message.

The mrtg installiation guide saids that 5.00404 or later version is required.

Give it a try and good luck.

Rgds,
Philip

[Philip Chan_1]

Oaks, my mistake, the mrtg installation guide said

"at least version 5.005 is required for mrtg to work well."

not 5.00404 as I said in my last message.

~Philip

[ISG]

All,

thanks for the help.

swconfigure /* got SAM running again.

However, the .depot files indicated in Phillips email are not installing with swinstall. I get the error indicated below:

************************************************************************************
# swinstall -s /opt/mrtg-prep/jpeg-6b-sd-10.20.depot /opt/jpeg-6

======= 04/06/01 12:08:15 BST BEGIN swinstall SESSION
(non-interactive)

* Session started for user "root@gbr11nnm".

* Beginning Selection
* Target connection succeeded for "gbr11nnm:/".
ERROR: "gbr11nnm:/opt/mrtg-prep/jpeg-6b-sd-10.20.depot": An I/O
error occurred while performing this task.
* Source connection failed for
"gbr11nnm:/opt/mrtg-prep/jpeg-6b-sd-10.20.depot".
WARNING: More information may be found in the daemon logfile on this
target (default location is
gbr11nnm:/var/adm/sw/swagentd.log).
* Selection had errors.



======= 04/06/01 12:08:16 BST END swinstall SESSION (non-interactive)

************************************************************************************
I get the feeling that i'm doind something fairly fundamental wrong. How can I remedy this problem?

BTW the concatenation of options for swinstall as listed previously won't work as listed.

Regards

Tim Haynes

[Steffi Jones_1]

Hello Tim,

i/o error seems to be still an ftp problem.
Before you install a depot you can always run the following command to see if the depot is ok:

tar tvf That doesn't unpack the tarball, but will list the files.

How do you use ftp? You need to make sure that you ftp in binary mode if it is a zipped file.

Then for the swinstall itself... try to go through the gui then you see a bit more what is going on.

You might want to set a mark in the following files so that you know where the install logging started and then you can search easier:

/var/adm/sw/swinstall.log
/var/adm/sw/swagentd.log
/var/adm/sw/swagent.log

Then start swinstall .... point in the sourcefile to the depot location (after you check that the depot is ok :-)).
Be careful it is case sensitive. (If you get a message about there is not a depot software in the source doublecheck the spelling)
Then go through the action scroll down -> mark the software and then -> install analysis.

If the depot file is ok and install still fails cut and paste the info from the logfiles here so that we can have a look.

Steffi Jones

[Philip Chan_1]

Tim,

When you download these depots, are they in gzip'ed formats? that is, they should all be ended with ????.depot.gz. What happens when you ran the gunzip command on them?

Make sure these files are being downloaded or transmitted as binary files.

Rgds,
Philip

[ISG]

All of the files have either come from the HP site or from the HP-UX porting and archiving centre. So far i've tried both HTTP and FTP transfers via netscape.

I tried running swinstall with no parameters to bring up the gui version. When you try to change the source to the directory containing the good depots the following error is returned:

"Cannot establish a lock on this target because of an external error (for example, the lock file could not be created).

Any ideas?

[Steffi Jones_1]

Hello again,

run the following command:

ps -ef | grep sw

and see if there is another swinstall process running.
Make sure that there isn't anything else running but usually swapper (which has nothing to do with swinstall just shows up when grepping for sw) and swagentd.

To be on the safe side kill -9 swagentd and restart it by typing
#/usr/sbin/swagentd

Then try the swinstall again

Steffi Jones

[Philip Chan_1]

Tim,

Restart swagentd then try the swinstall command again,

/sbin/init.d/swagentd stop
/sbin/init.d/swagentd start

That should clear the lock file, if not then you'll have to remove the lock file manually using the rm command.

When running the swinstall command, no need to mention the destination directory, all these depot files were defaulted to /opt.

Rgds,
Philip

[ISG]

Steffi / Phillip

Tried what you suggested, except with one important safety aspect... my sysadmin at unversity once left off the - on a kill -9 and killed the 9 the process on the stack. I digress, the results of killing the process and stopping and starting swagent are below. Do you know why this number of files couldn't be deleted?

# ps -ef | grep swa
root 0 0 0 Apr 5 ? 0:02 swapper
root 15898 15864 1 17:51:06 pts/2 0:00 grep swa
root 4952 1 0 Apr 5 ? 0:00 /usr/sbin/swagentd -r
# kill -kill 4952
# ps -ef | grep sw
root 0 0 0 Apr 5 ? 0:02 swapper
root 15900 15864 1 17:51:26 pts/2 0:00 grep sw
# /sbin/init.d/swagentd stop
The swagentd daemon is stopped.
# /sbin/init.d/swagentd start
* Removing /sbin/reboot.prev
* The following files, which could not be closed by swinstall
when they were updated, are being removed now:
/usr/lib/#libfmtbtlan3.sl could not be removed
/usr/lbin/#swagent
/usr/sbin/#swagentd
/usr/sbin/#swverify
/usr/sbin/#syslogd could not be removed
/usr/obam/lib/#libobam.1
/usr/sbin/#automountd could not be removed
/usr/sbin/#nfsd could not be removed
/usr/sbin/#rpc.lockd could not be removed
/usr/sbin/#rpc.mountd could not be removed
/usr/sbin/#rpc.statd could not be removed
/opt/dce/sbin/#dced could not be removed
/usr/lib/#libcma.1 could not be removed
/usr/lib/#libdce.1 could not be removed
/usr/lib/#libdcedpvt.1 could not be removed
/usr/dt/bin/#dtexec could not be removed
/usr/dt/bin/#dtfile could not be removed
/usr/dt/bin/#dtlogin could not be removed
/usr/dt/bin/#dtsession could not be removed
/usr/dt/bin/#dtterm could not be removed
/usr/dt/bin/#dtwm could not be removed
/usr/dt/bin/#rpc.ttdbserver could not be removed
/usr/dt/bin/#ttsession could not be removed
/usr/dt/lib/#libDtHelp.1 could not be removed
/usr/dt/lib/#libDtSvc.1 could not be removed
/usr/dt/lib/#libDtTerm.1 could not be removed
/usr/dt/lib/#libDtWidget.1 could not be removed
/usr/dt/lib/#libtt.1 could not be removed
/usr/lib/security/#libpam_unix.1 could not be removed
/usr/lib/Motif1.2_R6/#libXm.2 could not be removed
/usr/lib/X11R5/#libX11.1 could not be removed
/usr/lib/X11R6/#libICE.1 could not be removed
/usr/lib/X11R6/#libX11.2 could not be removed
/usr/lib/X11R6/#libXext.2 could not be removed
/usr/lib/X11R6/#libXhp11.2 could not be removed
/usr/lib/X11R6/#libXt.2 could not be removed

#
Have a good weekend,

Tim Haynes

[Philip Chan_1]

Tim,

Restart the server will remove all these unremovable lock files for you, then you can start over again.

I checked and found that process id 9 is the "strmem" command. Not sure what this process does but for sure that is a system related one.

Rgds,
Philip

[ISG]

I have made loads of progress with this having shutdown and rebooted the machine. All of the pre-requisites for MRTG have installed from .depots and are listed by swlist as shown below...
******************************************************************************
# Product(s) not contained in a Bundle:
#

PHSS_17566 B.10.00.00.AA CDE Runtime Feb 99 Patch
SOP-BASIS 7.05 iVISION V7 - BASIS
SOP-CONNECT 7.05 iVISION V7 - CONNECT
binutils 2.10.1 binutils
freetype 1.3.1 freetype
gcc 2.95.2 gcc
jpeg 6b jpeg
libpng 1.0.6c libpng
perl 5.6.0 perl
samba 2.0.7 SMB-based file/print server
xanim 2.7.3 xanim
xpm 3.4k xpm
zlib 1.1.3 zlib
#
******************************************************************************

When I try and swinstall the MRTG depot, the logfile shows that some of the dependencies are apparently missing:
******************************************************************************
======= 04/09/01 10:03:25 BST BEGIN swinstall SESSION (interactive)

NOTE: The interactive UI was invoked, since no software was
specified.

* Session started for user "root@gbr11nnm".

* Beginning Selection
NOTE: The software "mrtg,r=2.8.12,a=HP-UX_B.10.20_700/800,v=HP-PD"
was successfully marked, but it depends on the following
software items which could not be found in the source.
However, these items may already be in the target. This will
be checked during the Analysis Phase: gd.gd-RUN
libpng.libpng-RUN zlib.zlib-RUN

* Source: gbr11nnm:/var/spool/sw
* Targets: gbr11nnm:/
* Software selections:
mrtg.mrtg-RUN,r=2.8.12,a=HP-UX_B.10.20_700/800,v=HP-PD
* Beginning Analysis
* The target "gbr11nnm:/" failed Analysis, so the task cannot be
executed. For more information on this failure, press the
"Logfile ..." button.
* "gbr11nnm:/": The software dependencies for 1 products or
filesets cannot be resolved.
* Ending Analysis
******************************************************************************

Are the libraries installed properly? In the Unix instructions for MRTG it refers to makefiles for each of the libraries. Is it possible necessary to run these even though the software has been installed as a dynamically linked binary from a depot and should hence be pretty much configured? I have tried to check this against zlib by doing ./configure which returns a "not found" error, and also trying to make zlib which also does not work.

All efforts to help much appreciated.

Tim Haynes

[Philip Chan_1]

Tim,

Seem like the gd library was missing from your installation list,

http://hpux.cs.utah.edu/hppd/hpux/Development/Libraries/gd-1.8.4/

Install the above library then try the mrtg depot again.

You should still be able to compile these source code but I would suggest to remove those depot library first to avoid confusions.

Don't give up, you'll get there. :-)

Rgds,
Philip

[ISG]

Still not working. Checked swlist, all the libraries are present. When swinstall unpacks a depot and installs it, does it do the equivalent of running a makefile and compiling the contents of depot? I ask as swinstall for the MRTG depot is reporting several dependancies as not found and hence aborting the installation.

Do I have to use ./configure for each library?
If so what do i have to configure so that this will work as ./configure as described in the docs for each of the libraries doesn't work, eg

==================================================

# cd /opt/libpng
# ./configure
/sbin/sh: ./configure: not found.
#
# cd /opt/libpng
# ./configure
/sbin/sh: ./configure: not found.
#
# cd /opt/libpng
# ./configure
/sbin/sh: ./configure: not found.
#

==================================================
At least this is progress....

At what stage is it safe to delete .depot files? Will an installation ever require material from a .depot file once fully installed and configured?

Regards

Tim Haynes

[Philip Chan_1]

Hi Tim,

If you install the depots, there is no need to run the ./configure, make and make install commands. These commands won't run because the depot files don't come with source codes. As soon as the mrtg depot file (and its dependency depots) went in the system fine with no error, the mrtg executable files will be under the /opt/mrtg/bin directory. Once reached this stage all depot files downloaded previously can be removed.

The ./configure, make and make install commands are only needed IF you downloaded the source code and decided to compile the program yourself.

Rgds,
Philip

[ISG]

Thanks for the clarification on the role of ./configure and make with .depot files. I found the problem using swconfig \*, which was a bad patch and a corrupted libpng. All the libraries are now in place, MRTG is installed, my only problem is that when I try to run either MRTG of configmaker I get errors returned. I think this is because of problems with perl. Perl5 is installed, but when I run perl -v to get the version I get the same perl 4 info as before installing perl5 (a 1993 version of perl 4).

Is there a way that I need to refer to perl5 or an environmental setting I must change so that it is always used.

Also are there any other possibilities (other than version problems) why I could be getting this output when attempting to run MRTG?

(BER is a .pl file in the mrtg directory which is used by mrtg. Results are the same whether or not there are any parameters given).

===============================================
# perl cfgmaker
syntax error in file cfgmaker at line 13, next 2 tokens "use BER"
syntax error in file cfgmaker at line 28, next 2 tokens "snmpmapOID("
syntax error in file cfgmaker at line 189, next 2 tokens "GetOptions("
Spurious backslash ignored at cfgmaker line 189.
syntax error in file cfgmaker at line 200, next 2 tokens "chomp("
syntax error in file cfgmaker at line 258, next 2 tokens "chomp("
syntax error in file cfgmaker at line 271, next 2 tokens "->"
syntax error in file cfgmaker at line 280, next 2 tokens "my("
syntax error in file cfgmaker at line 296, next 2 tokens "->"
syntax error in file cfgmaker at line 300, next 2 tokens "pretty_print $_"
syntax error in file cfgmaker at line 308, next 2 tokens "})"
cfgmaker has too many errors.
#
===================================================

Many thanks. Must be somewhere near to solving this now!

Regards

Tim Haynes

[Philip Chan_1]

The Perl v5.6 binary you installed would be seating under /opt/perl/, and that the mrtg program probably reference perl through either /usr/bin/perl or /usr/local/bin/perl, therefore for fixing the problem on wrong perl being called you should re-create the following symbolic links,

ln -s /opt/perl/bin/perl /usr/local/bin/perl
ln -s /opt/perl/bin/perl /usr/bin/perl

After that any call to perl would reference the perl binary under /opt/perl/bin.

Don't forget mrtg requires Perl 5.005xx, the default one comes with HPUX is only version 4.x.

Rgds,
Philip

[ISG]

I tried creating the link to the perl executable as described, but can work around by invoking perl using the full path of the executable. Is there anything else i can do to cause perl and MRTG to run without explicitly stating the path to the executable.

MRTG is now running and producing results.