Les Mikesell wrote:
Craig White wrote:
----
openNMS isn't packaged or distributed with Fedora is it?
No, I'm not interested in being restricted to the subset of programs
that are included in a distribution. Are you?
----
not if you run
alternatives --config java # and set it to Sun's installation
But it doesn't work with Sun's RPM, which my point.
----
it doesn't? It has worked for me on Fedora 7/8 CentOS 5 and RHEL 5
I must be lucky then.
----
It's more than luck. It's a miracle if that happened after just
installing Sun's RPM.
----
And RedHat does for their paying up2date customers, while still
claiming they "can't" redistribute for fedora users:
http://rhn.redhat.com/errata/RHEA-2007-0582.html
----
but that is on a separate CD and isn't installed by anaconda. It's no
different than you can download directly from Sun and it isn't even the
current version
----
Ummm, somehow I'd expect a package named
java-1.5.0-sun-1.5.0.13-1jpp.1.el5.i586.rpm to have the jpackage style
additions that RH makes necessary instead of being the stock Sun rpm.
seriously though, java just hasn't been a problem for me and I've been
fooling with it quite a bit lately with Alfresco, docbook-XSL and even
managed to implement ruby-java-bridge for ongoing Ruby on Rails
development.
It's not completely impossible to make it work but not trivial and I
think you have to admit that you aren't an average user.
----
The only straightfoward way I've found is the yummable version at
the opennms site, with dropping the sun binary under /usr/java and
replacing every shred of the alternatives system you can find with
direct symlinks as a distant second.
----
again...opennms is not a fedora/redhat package so it's pre-requisites
are not of fedora packaging concerns.
Yes, that's a generic complaint that the packagers don't give a crap
if anyone else's stuff works or about cooperating with anyone else.
Your comment seems to imply that should be assumed and accepted.
Do you really run opennms on a
Fedora system anyway? I thought you were more inclined to install stuff
like this on an 'Enterprise' type server.
No, but historically if something is broken in fedora, it will be
equally broken for the next 7 years when the RH cut happens. They
fixed the brokenness after the fact in RHEL5 with the package I
pointed out, but CentOS doesn't carry it and fedora users don't get it.
I just looked at the openNMS site and it appears that java isn't
included in openNMS packages so you still have to manage a separate
install.
You can install it separately if you want, but their yum repository
includes the jdk. Click/install the appropriate yum config from
http://yum.opennms.org/ (you'll want the 'unstable' version). Then
'yum install opennms' to get everything and you are up to the
'Configure OpenNMS' heading on
http://www.opennms.org/index.php/Installation:Yum.
A few minutes compared to several weeks of looking for jpackage'd SUN
instructions before that - Oh, and the CentOS5 tomcat didn't work with
the Sun JDK until an update a few months after release because the
jars were built with the broken included java - apparently RH fixed
theirs somewhat earlier but Centos didn't catch it. This version
doesn't need tomcat but the earlier ones did.
By the way, I've been using Zenoss which appears to be similar to
OpenNMS...have you any comparison to offer?
Haven't used Zenoss, but OpenNMS compares favorably to anything I've
ever seen in terms of autodiscovery and assuming that you have enough
machines that you don't want to see them all on the screen at once. It
auto-discovers services and notifies you when they stop, and graphs
interface/cpu/memory/disk SNMP values with sensible defaults.
Considering the huge framework underneath it, I'm impressed by the
current rapid development without breaking anything. As an example of
what it can do, if you enable link discovery and have snmp on your
switches it will show what devices are connected to each switch port.
It can do maps, but that's not a real strong point. It's better at
consolidating the problems on a viewable screen and doing
notifications on errors and thresholds. It's weak link is that some
of the configuration still has to be done by editing xml files
although each revision moves more control into the web interface. I'm
also impressed by the ability to grab the svn source and rebuild a
trunk snapshot with the build script pulling in all of the components
you need.
----
I think its amusing that Linux browser plugins haven't worked for so
long, yet it is so highly touted.
----
which ones don't work for you? That hasn't been an issue for me
64 bit java and flash (both are supposed to work in Solaris), and
probably others.
----
I had hoped that Nexenta was going to give us the perfect
combination of OpenSolaris with zfs and an up to date Ubuntu based
userland, but the team seems to have gotten sidetracked building a
commercial file server appliance first. Maybe Apple will get their
zfs out soon.
----
begin holding your breath now. When Apple does get around to releasing
something like this, it should only take a few updates to actually get
it to work as they seem stuck in a perpetual beta loop. Apple
continually ships broken software - i.e. Back to My Mac
http://db.tidbits.com/article/9346 / Quicktime which has had a horrible
year wrt security issues and on and on.
So which one is perfect? There's nothing particularly mac-specific in
the problems of connecting inbound through NAT routers. At least Apple
doesn't just say 'you can't have it because its license isn't
restrictive enough to be called free'. And they don't go out of their
way to make their system difficult to use with 3rd party programs -
mostly, anyway.
I recall getting java from Sun because Open Office said it would not
work well without it. So spent part of a day getting it working BECAUSE
FEDORA DOES NOT PLAN FOR A USER TO TO THIS, BUT COULD, and finally got
the little man in the box to jump around on the web page.
Went to Open Office and tried all of them and really can't say I saw
any difference. So either I can't see what it did or it didn't do much.
Karl
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7
