topic Re: MRTG / GCC / SAM in Operating System - HP-UX

MRTG / GCC / SAM

ISG — Thu, 05 Apr 2001 15:51:02 GMT

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?

Re: MRTG / GCC / SAM

Carsten Krege — Thu, 05 Apr 2001 17:03:53 GMT

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

Re: MRTG / GCC / SAM

Steffi Jones_1 — Thu, 05 Apr 2001 17:26:19 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Fri, 06 Apr 2001 07:54:21 GMT

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

Re: MRTG / GCC / SAM

Printaporn_1 — Fri, 06 Apr 2001 07:58:11 GMT

Hi,

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

Re: MRTG / GCC / SAM

melvyn burnard — Fri, 06 Apr 2001 08:11:55 GMT

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

Re: MRTG / GCC / SAM

ISG — Fri, 06 Apr 2001 09:07:14 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Fri, 06 Apr 2001 09:30:26 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Fri, 06 Apr 2001 09:39:25 GMT

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

Re: MRTG / GCC / SAM

ISG — Fri, 06 Apr 2001 10:04:10 GMT

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

Re: MRTG / GCC / SAM

Steffi Jones_1 — Fri, 06 Apr 2001 11:53:23 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Fri, 06 Apr 2001 13:23:30 GMT

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

Re: MRTG / GCC / SAM

ISG — Fri, 06 Apr 2001 13:44:43 GMT

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?

Re: MRTG / GCC / SAM

Steffi Jones_1 — Fri, 06 Apr 2001 14:16:09 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Fri, 06 Apr 2001 14:17:45 GMT

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

Re: MRTG / GCC / SAM

ISG — Fri, 06 Apr 2001 15:47:38 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Sat, 07 Apr 2001 00:08:22 GMT

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

Re: MRTG / GCC / SAM

ISG — Mon, 09 Apr 2001 08:23:31 GMT

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

Re: MRTG / GCC / SAM

Philip Chan_1 — Mon, 09 Apr 2001 08:44:20 GMT

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

Re: MRTG / GCC / SAM

ISG — Mon, 09 Apr 2001 09:10:33 GMT

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