[conspire] (forw) Re: June 25/July 9 MP installfest RH 7.3 PC to Centos56 more/less done

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Thu, 14 Jul 2011 16:08:47 -0700
From: Rick Moen <rick at linuxmafia.com>
To: wood eddie <ewood111 at yahoo.com>
Subject: Re: June 25/July 9 MP installfest RH 7.3 PC to Centos56 more/less
	done
Organization: If you lived here, you'd be $HOME already.

Quoting wood eddie (ewood111 at yahoo.com):

> Thanks again for great support. Followed instructions. Ran
> modern yum command to fetch xorg package, finds that its already
> done. Use rpm command to xorg package install from CentOS DVD, says
> package mentioned already installed. Next, backup xorg.conf to
> xorg.conf-conf, ran Xorg -configure. I did not remember what happen
> next. Finally reboot PC, after signon, ran startx, and CentOS screen
> finally comes up. Hooray. 

Glad to hear it.  What I said about anaconda omitting Xorg drivers you 
didn't then need was (obviously) only my surmise.  It now appears that
anaconda dropped the whole kitchen sink into your system, which turned
out to be handy, and all you needed to do was induce Xorg to reprobe
your hardware and create a new /etc/X11/xorg.conf file.

> I shall play around with this, as its different than RH73.

Well, yes.  Much time has passed.  If you want to get an idea of what's
occurred in the interval since RHL 7.3, see this version history:
'RH Releases' on http://linuxmafia.com/kb/RedHat/

> Will start to install Tomcat and apps next.

A few words about that:  (As an aside, a bunch of these things I've been
telling you that are non-obvious to users, such as do NOT look to
hardware manufacturers for Linux hardware drivers unless you have no
better alternative, need to go into the 'I've installed Linux; now what?' 
pamphlet I keep meaning to write.)  

You want to _seriously_ attempt to stick to software in the best
maintained, most RH-compatible form, and resist the urge to go to
'upstream' Web sites and download tar.gz (or similar) archives not
tailored for RHEL/CentOS.  You need to maintain a very strong prejudice
in favour of maintained distro packages.  And that includes Tomcat.

Here is my magazine editorial footnote where I explained several reasons
for this recommended prejudice, in reply to a magazine author who'd been
(unwisely) recommending that readers fetch software from 'upstream'
tarball (tar.gz) sources:

http://linuxmafia.com/~rick/weatherwax.html#1

Quoting the footnote:

   Depending on your distribution, you may find that there are update
   packages available directly from the distribution's package updating
   utilities, or from ancillary, semi-official package archives (e.g., the
   Fedora Extras and "dag" repositories for Fedora/RH and similar
   distributions), or, failing that, third-party packages maintained by
   reputable outside parties, e.g., some of the Debian-and-compatible
   repositories registered at the apt-get.org and backports.org sites.
   Although those are certainly not unfailingly better than tarballs, I
   would say they're generally so. 

Searching the Web for 'tomcat centos' brings up classically bad advice
as your first hit:

http://www.satollo.net/how-to-install-tomcat-and-java-6-on-centos-5-2

  How to install Tomcat and Java 6 on CentOS 5.2

  I'm not very smart on installing packages on Linux, but today I
  need to configure a Tomcat on a CentOS 5.2. The CentOS 5.2 has Tomcat 5
  available as yum package, with gcc-java. But Java gurus tell me to use
  the original Sun JDK to run Tomcat without problems. I know that Tomcat
  can run with a JRE which is a lot smaller, so I started with download
  the Java JRE 6 Update 11 from here
  (http://java.sun.com/javase/downloads/index.jsp).


Let me unpack that for you, and explain the issues.  Sun Microsystems
invented Java and made JRE/JVM software available for various platforms
including Linux i386.  That software was proprietary because Sun was
a control freak.  Gradually most of Sun Java was open-sourced but many
of the libs remained proprietary, and Sun applied numerous other
control-freak measures such as mandatory certification compliance to
keep full control.  Nonetheless, the effort at a fully open source Java
environment outside Sun's control gained traction over the years.  One 
of the leading actors in making that happen was Red Hat Software, Inc.,
which kept pushing and improving OpenJDK to make it fully Java
1.6-complaint, and replace the proprietary 'plugs' and libs with open
source replacements such as their improved version of GNU Classpath.
E.g., from 2008, see: http://fitzsim.org/blog/?p=17

See also:  'Java' on http://linuxmafia.com/kb/Devtools
(My own mostly outdated snapshot of the initiative to make Java
fully open source, on Linux.)

Nonetheless, a lot of the information you will find on the Internet
advises you to immediately go download a huge pile of proprietary Sun
Microsystems (now, Oracle) code in unpackaged format and mangle your
system by running their proprietary installers and let those hurl pieces
of code god-knows-where into various corners of your system with root
authority.  That advice comes from the Java mafia, who in general really
aren't Linux people but rather Sun Solaris (or Mac OS) people who don't
give a damn about Linux or open source, don't care whether _your_ system
remains manageable, and never met a piece of brittle, unmaintainable,
overengineered proprietary software they didn't like.

OpenJDK w/GNU Classpath was bundled as the standard Java implementation
directly into RHEL5 (as a standard distro package) starting with RHEL5
Update 3, and thus also is in CentOS 5.3 -- and later versions such as
the CentOS 5.6 that you have.

> By the way, I ran which java and finds that /usr/bin/java already
> installed, as is also JDK 1.6, which eliminates something I was going
> to do on RH73.

Just for clarity, _that_ is OpenJDK, as bundled and improved by Red Hat
Software / CentOS.


Searching for 'openjdk centos tomcat' finds this as hit #8:
http://www.readmespot.com/question/f/14838/installing-tomcat-on-centos-5

You'll notice that advice on the Internet about how to do Tomcat on
CentOS the open source way rather than the Sun / Solaris / MacOS
proprietary way tends to get outshouted, thus is a little more difficult
to find.  You have to read the search results critically to find someone
who has a clue.  Even the readmespot.com page (cited) has answers with
clue and without.  I refer you specifically to the answer described as
#3:

  Is Tomcat6 the requirement? What version of Centos? (I'm assuming
  "Tomcat of some sort" and "current Centos" which would be 5.3 as of this
  writing)

  You don't need the jpackage repo unless you want Tomcat 6. Also, Centos
  5.3 ships with openjdk 1.6.0, which has passed the Java SE 6 TCK.

  Simply "yum install tomcat5" should pull in all the dependencies you
  would need (including openjdk), many of which will be based off the
  jpackage sources. Once it's installed, all you need is "service tomcat5
  start" to start it up. NOTE: Running your web container as root is very,
  very bad because it is a massive security risk. The tomcat5 service
  installed by the repository version will drop its permissions to a
  'tomcat' user with more limited permissions. To have tomcat start
  automatically when the system boots, use "chkconfig tomcat5 on".

  In your case above, the port 8080 is probably blocked by the default
  firewall. You can turn the firewall off (recommended only for testing
  connectivity, do not run without the firewall in production) with
  "service iptables stop". Centos provides both a GUI and Text UI tool
  (system-config-securitylevel and system-config-securitylevel-tui
  respectively) for modifying the firewall, or you can use iptables
  directly (see 'man iptables').

  Posted by Ophidian


Even CentOS's official pages on the subject, because they are old and
obviously need a refactoring and rewrite, still reflect the old
pre-2008-ish situation where you had little choice but to install either
Sun's or IBM's proprietary Java implementations, if you wanted a Java
fully compatible with Sun's J2EE 1.6 Technology Compatibility Kit, and
pushed readers towards installing such software and thereby
circumventing and compromising system management via RHEL/CentOS's rpm
package regime.  But you can see them start bringing things up to date
with the 'Special note':

http://wiki.centos.org/HowTos/JavaOnCentOS

  SPECIAL NOTE: Starting with CentOS 5.3 the upstream source for SRPMs,
  which the project rebuilds into the base and updates repositories, has
  added the openjdk product into the freely available sources as part of
  its distribution. As such, the CentOS project can now ship an integrated
  Java implementation. Using this approach can greatly simplify
  installation matters and we encourage you to consider using the proper
  subset from the following newly provided packages & filing bugs
  upstream, if problems are noted.

  [user at host ~]$ sudo yum list \*java-1\* | grep open 
  java-1.6.0-openjdk.x86_64                 1:1.6.0.0-0.25.b09.el5 base
  java-1.6.0-openjdk-demo.x86_64            1:1.6.0.0-0.25.b09.el5 base
  java-1.6.0-openjdk-devel.x86_64           1:1.6.0.0-0.25.b09.el5 base
  java-1.6.0-openjdk-javadoc.x86_64         1:1.6.0.0-0.25.b09.el5 base
  java-1.6.0-openjdk-src.x86_64             1:1.6.0.0-0.25.b09.el5 base
  [user at host ~]$
  [...]

I hope you get the overall picture:  Online information about Java on
Linux (including CentOS) still overwhelmingly pushes you towards mucking
up your system using Sun proprietary Java, _but_ CentOS (and Fedora) 
gives you your absolute best platform on Linux for fully functional 
open-source Java using real distribution packages rather than squirrely 
'upstream' software installed manually.  And you should therefore resist 
doing the latter unless there truly, really _is_ no way to make
something work without the proprietary stuff (within reason).

That having been said, in fairness I'll need to qualify what I just
said:  Java _not only_ has had a long prior history of proprietary
dependencies before Red Hat Software, Inc.'s (and others')
groundbreaking improvements, but _also_ Java is all about class libraries.
There is an endless variety of J2EE class libraries -- and you never
know when you'll suddenly encounter some, say, third-party Java apps
that implicitly expect methods and functions provided only by
proprietary class libraries that have not yet been reverse-engineered
and reimplemented in open source.

In that case, you _may_ wish to make the judgement call of installing a
full Sun JDK stack -- but please be aware that there's a price to pay,
in that you're installing a bunch of stuff that is not under system
package management and will be poorly maintainable.  Therefore, resist
doing it unless and until you feel you must (if ever).  Every single
time I've installed significant system software from upstream source
tarballs or other non-distro sources, it's lead to problems later.

And, in particular, you absolutely will _not_ need to do that just to
get something as simple as Apache Tomcat going.

Anyway, as you'll see in
http://mirror.centos.org/centos/5.6/os/i386/CentOS/ , CentOS 5.6
provides a full set of maintained distro packages for Tomcat 5.5.23, 
so, as 'Ophidian' said, unless for some reason you insist on rushing to
adopt Tomcat 6, you can simply install everything you need using 'yum
install [packagenames]'.

Web-searching 'tomcat6 centos' finds several pages explaining how even
Tomcat 6 can be achieved without breaking your package regime more than
a little.  E.g., the first and second hits
explain how to add an additional 'yum repository' reference to your
package system so that you can pull down unofficial rpms for Tomcat 6
that are CentOS5-compatible from a jpackage.org rpm repository.  That's
slightly less desirable than official distro packages, from the point of
view of maintaining the good condition of your system, but far better
than downloading and installing a bunch of tarballs.

On the other hand, the third hit advises the reader to download and
install a bunch of tarballs, which is exactly what you should resist.

I hope that helps.



----- End forwarded message -----