Further adventures with RH7.2

Jonathan Hutchins hutchins at opus1.com
Mon Apr 8 15:08:38 CDT 2002


Unfortunately, I'm unable to post the correct version numbers and other
details precisely this morning, since I'm relying on memory.  In spite of
the fact that I did ssh out of my system last night to an external host, and
verify that I could ssh back in, this morning it doesn't work.  I can't
access the system directly via ssh, and I can't access it from the system I
thought I'd confirmed.  I suspect that the answer may lie in the conversion
from initd/tcpip wrappers to the new xinetd, given that the RedHat
conversion/upgrade scripts are often the suspects in such things.

There are other disappointments as well.

One of the things that prompted this upgrade was a desire for finer
monitoring and control of the firewall system, with the ability to track and
potentially block some traffic that I felt was wasting a lot of productive
time.  Generally, I don't philosophically support such activities - I feel
that if someone's doing their job, it doesn't matter what else they do, and
if not there's a management problem.  In this case, though, it's a domestic
issue, I'm not a manager, and the job in question is clearly not getting
done.  Enough "noise" on the obsessive activity might make it unattractive
enough for the concerned party to get back to business.

Both ntop and ethereal had been recommended as potential network monitors,
with ethereal being rejected for about 58 first level dependency failures
(not counting the dependencies that might fail for the 58 required
packages).  Ntop required fewer upgrades, but I gave in and decided that an
upgrade was pretty much due by now.

The problem is, now that I've upgraded, the dependencies take up two pages
for either one of these.  Ethereal apparently requires the X system to be
installed.  On a server.  Hello, is this Microsoft?

Ntop is also asking for graphics libraries and file handlers.  Ok, I know
it's trying to build pretty picture graphs and serve them over a web-like
interface.  Couldn't that be a modularized option?

And that's where we stand this morning.  I've spent several hours shuffling
the two RH7.2 CD's in attempts to resolve dependencies.  Without the GUI
package manager, you're pretty much on your own to track down dependencies,
and then those packages have their own dependencies, and pretty soon the
back of the envelope is covered with scrawled package names.  The packages
are, of course, scattered between the two CD's, so I'm swapping in and out
trying to find a way to install things in such an order that I can actually
do this, since rpm won't ask you to swap CD's.  A second CD drive wouldn't
really make it much easier.

One of the available packages is a database of all of the rpm's on the two
CD's.  Unfortunately, there's not a clue about how you're supposed to be
able to use it.  Clearly it has nothing to do with RPMFIND or the base RPM
packages.  Possibly it is a part of yet another GUI tool not available on
such a small system.

Even all that wouldn't have stopped me this morning, but when it came down
to installing the lib... packages that gtk+ wanted, RPM decided to stop
reporting required packages and revert to required libXxxx.so files - and
there is no libX* package on either CD.

Several hours spent, with newer but slightly less functional software, and
considerably less disk space.  Why did I do this again?




More information about the Kclug mailing list