tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pyeron <ja...@pyeron.com>
Subject RE: RPMs [off topic: why rpm?]
Date Tue, 07 Jan 2003 20:41:07 GMT

IMHO:

You do have many valid points there. To justifty what we do here:

 We do not assume, the validity of any package (unless our support 
  contract covers it). That said we role our own RPMs here.

 We put together systems (servers?) for our clients. We need the assurance 
  that we can deploy a patch, update, or new software on these machines. 
  We use RPMs and MSIs for this reason.

 If you have a hundred RedHat 7.x and fifty Win2k machines out there 
 running slightly different flavors of your product, you would use (need?) 
 this type of mgmt system.

On Tue, 7 Jan 2003, Turner, John wrote:


Believe me, I understand what/why RPMs (and other package schemes) were
developed.  My point was that there is no need for them with Tomcat.  A
binary install does nothing to the system.  I change Tomcat installations
simply by changing a symlink.  There is only one dependency, and that is the
JDK.

I guess it comes down to a trust issue.  There's no guarantee that the
builder of an RPM did the right thing, nor that an RPM is secure or trusted.
All of my servers are RH servers, for example.  Unless I'm buying support
from Red Hat, any RPM is foreign and untrusted.  The only trusted RPM would
be one obtained from RH (appropriately signed) under an RH support contract.
In the time it takes me or another admin to dissect and analyze an untrusted
RPM's actions on a sacrifice box, we can install the app ourselves and have
exact, explicit control over how it gets installed.

RPMs and a lot of the other package schemes I've worked with over the years
have a myth about them...people assume that because it's an RPM that
everything is OK.  That's a bad assumption to make, and all due respect,
it's not wise to base corporate policy on bad assumptions.  At my company,
the administrators install and configure things themselves, and track it all
in a maintenance tracking system for future reference.  After all, an RPM
can't make any decision about dependencies and interactions if there are
custom applications installed; and RPM only knows what it knows, and how can
Joe RPMBuilder on the other side of the world know what you've done to your
server?  I guess for a "plain vanilla" server that only performs basic
services and is the same as everyone else's, that would be OK, but for any
server that has proprietary applications installed or custom compiled
versions of common software, blindly installing a RPM, accepting what it
does, and believing everything will be OK just because it's a RPM is
foolish.

John

> -----Original Message-----
> From: Jason Pyeron [mailto:jason@pyeron.com]
> Sent: Tuesday, January 07, 2003 12:27 PM
> To: Tomcat Users List
> Subject: RE: RPMs [off topic: why rpm?]
> 
> 
> RPMs provide transaction level control for system 
> modification. When you 
> install an application manually, you ASSUME that the 
> administrator has 
> investigated ALL interactions and dependences. Can correctly 
> uninstall the 
> package when needed, rembers it is installed.
> 
> Now rpm puts these details on the packager, who is assumed to have 
> knowledge of the workings of the application.
> 
> But lastly, there are services that can issue updates automaticly as 
> needed. Esp for security.
> 
> on RedHat there is the Red Hat Network
> on Windows there is windows update
> 
> That being said, our Systems admin are not allowed to install ANY 
> application, patch any software without using/creating a RPM. This is 
> company policy, the same goes for our windows boxes. 
> 
> -jason
> 
> On Tue, 7 Jan 2003, Turner, John wrote:
> 
> 
> Actually, the release builds have moved to a new scenario, 
> basically the
> same as Apache HTTP.  Tomcat release binaries are available 
> from various
> mirror sites.  On any given mirror, there are only /bin and 
> /src, and in
> /bin there are the full versions and the LE versions.  I 
> think RPMs went
> away with 4.1.17, though I could be wrong.
> 
> In any case, you can find pre-4.1.18 RPMs here:
> 
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/archives/
> 
> On that note, there's no need for an RPM for Tomcat, in my 
> opinion.  The
> only thing a RPM adds (AFAIK) is the creation of a tomcat user and the
> installation of a start/stop init script.  Both tasks are 
> easily completed
> manually, leaving just the need for the binaries themselves.
> 
> John
> 
> 
> > -----Original Message-----
> > From: Jason Pyeron [mailto:jason@pyeron.com]
> > Sent: Tuesday, January 07, 2003 12:08 PM
> > To: Tomcat Users List
> > Subject: Re: RPMs
> > 
> > 
> > i think the general tree structure is as follows:
> > 
> > 
> > /.../bin
> >     /rpm
> >     /src
> > 
> > 
> > different builds move around the tree, and not all builds 
> > have rpms (at 
> > least until some one builds them)
> > 
> > On Tue, 7 Jan 2003, Kevin Wilson wrote:
> > 
> > where are all the RPMs for the 4.1.X versions of Tomcat?
> > 
> > 
> > -- 
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > -                                                               -
> > - Jason Pyeron                   http://www.pyerotechnics.com   -
> > - Owner & Lead                  Pyerotechnics Development, Inc. -
> > - +1 410 808 6646 (c)           500 West University Parkway #1S -
> > - +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
> > -                                                               -
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > 
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information. If you
> > have received it in error, purge the message from your system and 
> > notify the sender immediately.  Any other use of the email by you 
> > is prohibited.
> > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:tomcat-user-help@jakarta.apache.org>
> 
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -                                                               -
> - Jason Pyeron                   http://www.pyerotechnics.com   -
> - Owner & Lead                  Pyerotechnics Development, Inc. -
> - +1 410 808 6646 (c)           500 West University Parkway #1S -
> - +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
> -                                                               -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> This message is for the designated recipient only and may contain 
> privileged, proprietary, or otherwise private information. If you
> have received it in error, purge the message from your system and 
> notify the sender immediately.  Any other use of the email by you 
> is prohibited.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:tomcat-user-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Owner & Lead                  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)           500 West University Parkway #1S -
- +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.




--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message