[Mongrel] The Debian Plan - reloaded

Filipe filipe at icewall.org
Fri Jan 12 13:06:42 EST 2007

On Fri, 12 Jan 2007, Jens Kraemer wrote:
> On Fri, Jan 12, 2007 at 09:09:33AM -0700, Kyle Kochis wrote:
> It's a known fact that a stable Debian lags somewhat behind the rest of
> the world in terms of software versions, so if you pick it you have to
> take that into account and be prepared to backport something if you want
> to live on the edge *and* stay on the Debian way of managing your
> software. I know, not everybody is in the position to pick *his* distro
> every time, and yes, Debian can give people a hard time in the
> beginning.

So is backports. If you want to stay using the debian's stable  version
of an package, you just point your mirros to security and wait for
developers to make security changes. But if you want touse new version,
you can find a lot of things at debian backports.

Mongrel package will not made it into etch - just for lenny. So we want to
create backports of it to etch.

> For the issues mentioned in the Mail you link to - the real bug here is
> with rubygems which doesn't fail if compiling a c extension fails, but
> happily ignores the error. So people think Mongrel installed correctly
> and blame Debian for it not working. If you saw the real error at gem
> install time, everybody could guess he needs a compiler and ruby-dev to
> compile things.

apt-get install gcc ruby1.8-dev
should solve it, no?

> [..]
>> One last point: Like any debian guy, I care about security and want to
>> have the latest patches and regularly do apt-get update and upgrade.
>> But because I manage a few high traffic sites that use ruby I also
>> must have plan if one (or more) of the sites get exploited because of
>> a new found security issue in ruby (or anything else for that matter).
>> Perhaps there are no new versions out that address this issue but
>> after some searching I find the root of the problem and make a patch.
>> So I use that patch to compile a secure version of that once exploited
>> software.
> you have some good points here and I really agree with you on the
> security patch thing.
> In fact, that's why I initially started maintaining my own set of
> ruby/mongrel debian packages. The point is I do this on one machine that
> is *not* a production system, and then just do an apt-get upgrade on the
> live servers.
> Having Mongrel officially in debian is just one step further, and makes
> it way easier to get started with maintaining your own mongrel packages.

After etch, there are a lot of things that ruby-extras team is planning
to ruby in Debian. You can expect to see more packages and softwares and
more compatibility. For example, one package that is being worked is
ruby-full (or something like this), that installs... hum... full ruby :D
So, we just ask some help for upstream developers, like create .tar.gz 
files, not only gems.

> Maybe that's only me, but I really prefer to do the whole patch-and-
> compile-part of the story only once. I take care for three and a half
> servers running Rails apps on Mongrel. That's not much but even then I
> have better things to do than e.g. to manually patch and install Ruby 4
> times when the next cgi.rb security leak arises.
> Imho, that's DRY applied to systems administration :-)

Me too! Do it once and let the rest of the world get it :D

filipe lautert

filipe { AT } icewall.org
Linux User        #279798
Jabber  lautert at jabber.ru

More information about the Mongrel-users mailing list