My reasons:
- source has the fixes first...critical on production servers,
especially for security fixes. With source, you don't wait for Red Hat
to release something. A lag of several days can mean the difference
between weathering a storm and spending the weekend scrolling through
logs and compiling forensic evidence for lawyers. The most recent
OpenSSH fix is a perfect example of this...all of my Red Hat servers
were patched by 9 AM the morning after the fix by building from
source...it was several days before Red Hat got around to releasing the
RPM for the same thing.
- source means you don't fight with everyone else in the world to
download the RPM when RH releases it on the Red Hat network. Many
organizations have policies that prohibit installing RPMs from any other
source...a corporate security officer would be nuts to let admins
install RPMs with doubtful pedigrees. Imagine someone setting up a "RPM
mirror site" that has the RPM you need, only its their "special
version". How would you know? Most people don't know how to check.
- source means you put the files where you want them to be. Everyone
has their own system, as does every company (or they should). With
RPMs, the files go where the RPM maintainer wants to put them...this may
or may not fit your environment...it rarely does on my systems. You can
spend more time reconciling the differences (and dependencies) than you
do just building from source.
- source means you know EXACTLY what was done to your system, you are
not relying on someone else...this is key if you are sleeping next to a
pager every night.
- source means you keep your installation tracking with the
authoritative source. I spent almost an hour explaining to an auditor
why my Apache's version numbers didn't match Red Hat's...the auditor
felt that RH's version number was the "safest" version number and that
any later versions released by Apache.org were "beta". His port scanner
found a later version number and kicked out a red flag. I don't have an
hour to hold someone's hand.
RPMs are great. I use them for things I don't really want to spend the
time to learn inside and out, like GNOME or whatever, typically
desktop-level packages. Package maintenance systems are necessary for
any environment with a multitude of systems. However, when it comes to
publicly accessible web services (Apache, BIND, MTAs, etc), I build from
source. Its not right or wrong, its just right for me. I think I got
spoiled after administering a slew of *BSD systems for a couple of
years...the ports tree is the shiznit.
John
Mike Millson wrote:
>I have not had any problems integrating tomcat w/ RH9 and Apache 2. Here
>is my write up on how to do this:
>
>http://www.meritonlinesystems.com/docs/apache_tomcat_redhat.html
>
>Granted, I'm not using mod_jk2, so maybe that is why I had no trouble.
>
>I have always heard it's better to compile Apache from source vs. using
>the rpms, but no one has ever quantified the advantages to doing this.
>Until someone does, and the advantages of compiling from source outweigh
>the advantages I've listed below for using the rpms, I still recommend
>using the rpms.
>
>There must be advantages to compiling Apache from source. Anyone want to
>be the advocate for this and explain why/when to compile from source?
>
>Thank you,
>Mike
>
>On Sun, 2003-10-05 at 12:09, Chong Yu Meng wrote:
>
>
>>Hi Mike !
>>
>>I guess the best way to test my theory is to try integrating Tomcat with
>>Apache 2 yourself. There are real benefits for using RH's rpms, but if
>>the integration takes too much effort, it may not be worth it. I haven't
>>touched Tomcat for about 4 months now, but when I was working on my
>>document for integrating Tomcat and Apache way back in May, I remember
>>having considerable trouble with RH9's Apache 2, which led me to use
>>Falsehope's rpms instead.
>>
>>Regards,
>>pascal chong
>>
>>
>>Mike Millson wrote:
>>
>>
>>
>>>There are two compelling benefits to installing the RedHat rpms:
>>>1) Updates and bug fixes can be installed automatically from the Red Hat
>>>Network (https://rhn.redhat.com/).
>>>2) Startup and shutdown scripts are already configured and available.
>>>
>>>I would like to weigh these benefits against any specific disadvantages
>>>to using the RedHat rpms.
>>>
>>>I know, this is a tomcat list, but I think it's relevant.
>>>
>>>Thank you,
>>>Mike
>>>
>>>On Sun, 2003-10-05 at 10:38, mail@(protected):
>>>
>>>
>>>
>>>
>>>>I am using RH9 with the Apache2 that comes with it. Recently I've installed
>>>>Tomcat5 with mod_jk2 without too many problems (jakarta-tomcat-5.0.7.tar.gz and
>>>>mod_jk2-ap20-2.0.1-1jpp.i386.rpm). Proper configuration of workers2.properties
>>>>and jk2.properties is essential I believe. I got a few sites running as virtual
>>>>hosts on Apache2 as well as on Tomcat5 and everything seems to be fine so far.
>>>>
>>>>http://archive.apache.org/dist/jakarta/tomcat-5/v5.0.7-alpha/bin/
>>>>http://archive.apache.org/dist/jakarta/tomcat-connectors/jk2/v2.0.1/rpms/
>>>>-> http://archive.apache.org/dist/jakarta/tomcat-connectors/jk2/v2.0.1/doc/
>>>>
>>>>Cheers,
>>>>Bart
>>>>
>>>>Quoting Mike Millson <mmillson@(protected)>:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I have heard the claims before about not using the default Apache that
>>>>>comes w/ RH 9, but I have never seen any concrete evidence for not doing
>>>>>this. Do you have any specifics such as articles or facts that show the
>>>>>downside of using the default Apache that comes w/ RH?
>>>>>
>>>>>Thank you,
>>>>>Mike
>>>>>
>>>>>On Sat, 2003-10-04 at 21:54, Chong Yu Meng wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Dave,
>>>>>>
>>>>>>Do NOT use the default Apache that comes with RH9 ! According to some
>>>>>>reports, there are some serious bugs inside it. I'm using RH9, but my
>>>>>>Apache comes from Falsehope.com
>>>>>>(http://ftp.falsehope.com/home/gomez/apache2/). It takes a bit of
>>>>>>tweaking, but you can get the Falsehope rpm to play nice with Tomcat.
>>>>>>
>>>>>>Regards,
>>>>>>pascal chong
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>For additional commands, e-mail: tomcat-user-help@(protected)
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>For additional commands, e-mail: tomcat-user-help@(protected)
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
