[Pkg-torrus-maintainers] Help with torrus 2.01?

[Marc Haber]

On Fri, Sep 16, 2011 at 09:20:05AM +0200, Bernhard Schmidt wrote:
> Am 16.09.2011 09:09, schrieb Marc Haber:
> >>1.) Upstream recommends using the FastCGI method for new
> >>installations, which has been causing a lot less problems than
> >>mod_perl in my experience. However, old installations will continue
> >>to use the old method. I don't see a way to migrate automatically.
> >>Should we
> >>  - not do anything
> >>  - add a note in NEWS.Debian and hope for people to see it
> >>  - add a debconf note
> >>  - ???
> >
> >Can we have packages that
> >- use fastCGI on new installs
> >- continue using mod_perl on updates,
> >- make migration from mod_perl to fastCGI as easy as possible,
> >- document this in NEWS.Debian?
> 
> Should be possible, at least for now. Everything necessary for
> FastCGI is in the -common package (except for the FastCGI server of
> course), people using torrus-apache2 will continue to use mod_perl.
> If they want to switch, they need to configure their server for
> FastCGI and then drop the -apache2 package.

Agreed. The -apache2 package is a remainder from the times when we
were still supporting apache 1.x, and the infrastructure was left in
place to probably support other web servers at some later time. I
guess that this is unlikely to happen (while FastCGI would make
supporting lighttpd quite easy, wouldn't it?)

> It would only get complicated if we wanted to migrate -apache2 to
> automatically use Apache2+mod_fcgid at some point, but to be honest
> I don't think it is worth the hassle. FCGI-Configuration is about
> five lines of Apache config, and there are way more FastCGI servers
> out there to be used. I'd point users to the documentation and be
> done with it.

Agreed. If you want, you could announce the end of mod_perl support in
wheezy+1 or wheezy+2, so that people are motivated to migate.

> >>2.) Upstream strongly recommends rerunning devdiscover and recompile
> >>the database on upgrades. I don't want to open the can of worms
> >>associated with an automated devdiscover, but recompiling the
> >>database would be possible. However, it can take literally ages to
> >>complete, doing that in postinst would be highly annoying since a
> >>lot of other services might be down during that time when running a
> >>dist-upgrade. So what to do?
> >
> >If torrus continues to run without a recompile in the majority of
> >cases, we should not do anything in the maintainer scripts. In my
> >experience, torrus updates were never a smooth thing due to Berkeley
> >DB breakage, so I reckon that user will be conditioned to read docs
> >and check torrus after upgrade anyway.
> 
> I have no idea whether it will continue running. I haven't tried a
> major upgrade yet. Especially not in conjunction with a dist-upgrade
> where the libdb-version also changes.

libdb changes have required nasty db_recover sessions in the past.
BerkeleyDB is one of the things I positively hate in torrus (next
being the xml configuration).

Did Stan include a MAX graph in the aggregated graphs (see the Thread
"Graphing Peak Bandwidth" on torrus-users from May 2005) in the mean
time? I have been wanting to submit that patch for years, but never
got confident enough to actually test it.

> I'm considering running the db-recover script on upgrades, any objections?

I don't know enough about berkeley DB. If it's harmless, do it. If
it can cause damage, make a backup. If it causes more damage than it
can help, don't do it.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190