I just did an install of RT 3 on Debian stable using the packages from
testing. (See the entry by MiroJuricic in the FAQ.)
It was very easy.
I had experience with RT 2 on RH 7.3 and that took quite a while to get
everything sorted out and working.
This time, I went from a bare Debian install to a working RT system in a
couple of hours. I did RT, RTFM, and the Statistics addon and it was a
piece of cake.
I can highly recommend Debian for anyone looking to setup RT.
Kudos to Andrew Stribblehill and Stephen Quinney for preparing the
Debian packages.
I just did an install of RT 3 on Debian stable using the packages from
testing.
Installing request-tracker3 from testing on a stable system pulls in
perl from testing which in turn pulls in libc6 from testing. So you
currently have a system that combines the disadvantages of Debian
stable (being grossly outdated being one of them) and Debian testing
(where “no security updates - packages with security updates might not
be updated for months if their dependencies are not satisfied” is one
of the most prominent ones).
As a Debian developer, I’d like to strongly discourage that kind of
setup on a production setup.
Since rt3 wants to see perl 5.8, it is currently not possible to run
rt3 on Debian stable without serious security implications.
I can highly recommend Debian for anyone looking to setup RT.
Unfortunately, I cannot concur with you.
Greetings
Marc Haber, Debian Developer
Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things.” Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Installing request-tracker3 from testing on a stable system pulls in
perl from testing which in turn pulls in libc6 from testing. So you
currently have a system that combines the disadvantages of Debian
stable (being grossly outdated being one of them) and Debian testing
(where “no security updates - packages with security updates might not
be updated for months if their dependencies are not satisfied” is one
of the most prominent ones).
So we should just not run request-tracker3 at all on a debian system?
Me, I tend to stay testing/unstable, but I have a less strict
definition of “production” than many.
honi soit qui mal y pense
~mindlace http://mindlace.net
Installing request-tracker3 from testing on a stable system pulls in
perl from testing which in turn pulls in libc6 from testing. So you
currently have a system that combines the disadvantages of Debian
stable (being grossly outdated being one of them) and Debian testing
(where “no security updates - packages with security updates might
not
be updated for months if their dependencies are not satisfied” is
one
of the most prominent ones).
So we should just not run request-tracker3 at all on a debian system?
Me, I tend to stay testing/unstable, but I have a less strict
definition of “production” than many.
We currently use rt2, but because we want to upgrade to rt3
I also chose for the option of using sarge+rt3 in a production
environment.
We currently have >60.000 tickets in rt, it is of major importance for
us.
With (just about) any distribution installing/upgrading rt is a major
pain in the …
Its (rt 3.0.11) bleeding edge dependencies aren’t even in gentoo’s
portage.
As a rule of thumb I only want to use software supported by the
distributions packages management.
So… that leaves a question…
Is it rt’s problem it always needs bleeding edge dependencies? or is it
the distributions we have to blame for (not) updating its packages? or
is it a larger problem of OSS and its very modular pillars?
debian stable is NOT
Re: [rt-users] RT 3 and Debian
a viable option in a LOT of production
environments.
</off topic>
Its (rt 3.0.11) bleeding edge dependencies aren’t even in gentoo’s
portage.
As a rule of thumb I only want to use software supported by the
distributions packages management.
So… that leaves a question…
Is it rt’s problem it always needs bleeding edge dependencies? or is it
the distributions we have to blame for (not) updating its packages? or
is it a larger problem of OSS and its very modular pillars?
RT is a relatively large perl application that stress-tests some things
that haven’t previously been well tested by perl applications. Because
of that, we find a fair number of interesting new bugs in perl and
various CPAN modules.
Its (rt 3.0.11) bleeding edge dependencies aren’t even in gentoo’s
portage.
To me it didn’t seem RT3 wanted anything at all ‘bleeding edge’ just
relatively current. The problem I did run into though was package
maintainers wanting you to install bleeding edge by writing their deps in
such a way.
As a rule of thumb I only want to use software supported by the
distributions packages management.
So… that leaves a question…
Is it rt’s problem it always needs bleeding edge dependencies? or is it
the distributions we have to blame for (not) updating its packages? or
is it a larger problem of OSS and its very modular pillars?
Little bit of both, but I feel it’s mostly the package maintainers fault
for tieing RT to such late packages. RT really only has a few packages
where it requires any version.
Installing request-tracker3 from testing on a stable system pulls in
perl from testing which in turn pulls in libc6 from testing. So you
currently have a system that combines the disadvantages of Debian
stable (being grossly outdated being one of them) and Debian testing
(where “no security updates - packages with security updates might not
be updated for months if their dependencies are not satisfied” is one
of the most prominent ones).
So we should just not run request-tracker3 at all on a debian system?
Me, I tend to stay testing/unstable, but I have a less strict
definition of “production” than many.
The problem with testing/unstable is that you don’t get any security
updates from the Debian security team. Additionally, testing might
have to wait for security updates for weeks of time since packages
do migrate from unstable to testing only if all dependencies are
satisfied.
I’d go for stable with backports of selected packages, but backporting
perl might be a bitch to backport. If security is not your premium
concern, I’d go for unstable with frequent updates, but straight
unstable and no funny mixtures.
Be aware that if unstable breaks (security, and run-wise), you get to
keep the pieces and will have to live with downtime while you fix the
system. If you know Debian well, that’s ok, but if you’re a Debian
newbie, it might leave you with big big problems.
Greetings
Marc
Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things.” Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
We currently use rt2, but because we want to upgrade to rt3
I also chose for the option of using sarge+rt3 in a production
environment.
I would recommend unstable. You get security updates in a much more
timely manner. OTOH, sid might break every day, and sarge breakages
are much less frequent. You need to carefully examine your preferences.
Maybe it would be a good compromise to run rt3 in a sid chroot hosted
on a Debian stable system. That way, backups are much easier and
faster to do, and you could probably run the database in the stable
host system.
As a rule of thumb I only want to use software supported by the
distributions packages management.
Neither Debian testing nor unstable get any “official” support. And
you can always roll your own .debs.
Is it rt’s problem it always needs bleeding edge dependencies? or is it
the distributions we have to blame for (not) updating its packages? or
is it a larger problem of OSS and its very modular pillars?
It is a little bit of all.
debian stable is not a viable option in a _LOT_ of production
environments.
Acknowledged. Unfortunately, sarge won’t release any time soon
This is a major headache.
Greetings
Marc
Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things.” Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
We currently use rt2, but because we want to upgrade to rt3
I also chose for the option of using sarge+rt3 in a production
environment.
I would recommend unstable. You get security updates in a much more
timely manner. OTOH, sid might break every day, and sarge breakages
are much less frequent. You need to carefully examine your preferences.
I also used to have this view.
I’ve just been through this. Sid broke twice in one week, and currently
remains broken. I’ve moved onto Sarge as a result.
As the debian co-maintainer for rt3 pointed out to me, the security
based fixes implemented in Sid usually get tagged high priority, so get
passed through to sarge reasonably quickly.
My scenario is only customers and staff with known IP’s can connect, so
this mitigates the security risk somewhat.
Maybe it would be a good compromise to run rt3 in a sid chroot hosted
on a Debian stable system. That way, backups are much easier and
faster to do, and you could probably run the database in the stable
host system.
Which is what I’ve done (db on woody). Also, Thanks to the excellent
design of RT, and the superfurryanimal powers of debian, it was possible
to quickly change front ends (s/sid/sarge/g) with no hassle. (i.e
migrate local hacks etc).
As a rule of thumb I only want to use software supported by the
distributions packages management.
Neither Debian testing nor unstable get any “official” support. And
you can always roll your own .debs.
Indeed. I know someone who has created the rt3 backport. I’ll ask if
they want to put this up somewhere.
Is it rt’s problem it always needs bleeding edge dependencies? or is it
the distributions we have to blame for (not) updating its packages? or
is it a larger problem of OSS and its very modular pillars?
It is a little bit of all.
debian stable is not a viable option in a _LOT_ of production
environments.
Acknowledged. Unfortunately, sarge won’t release any time soon
This is a major headache.
We currently use rt2, but because we want to upgrade to rt3
I also chose for the option of using sarge+rt3 in a production
environment.
I would recommend unstable. You get security updates in a much more
timely manner. OTOH, sid might break every day, and sarge breakages
are much less frequent. You need to carefully examine your preferences.
I also used to have this view.
I’ve just been through this. Sid broke twice in one week, and currently
remains broken.
I cannot confirm this. My sid systems are alive and kicking.
otoh, sid usually fails rather spectacularly, so checking update’s
implications on a staging system is reasonably painless.
As the debian co-maintainer for rt3 pointed out to me, the security
based fixes implemented in Sid usually get tagged high priority, so get
passed through to sarge reasonably quickly.
I have to disagree on that. priority high only shortens the wait
period. If a package’s dependencies cannot be satisfied in sarge, the
package doesn’t migrate to sarge even if the waiting period is over.
That way, a security update can be held from migrating to sarge for
weeks or even months.
My scenario is only customers and staff with known IP’s can connect, so
this mitigates the security risk somewhat.
It does, but I wouldn’t feel comfortable with this.
Neither Debian testing nor unstable get any “official” support. And
you can always roll your own .debs.
Indeed. I know someone who has created the rt3 backport. I’ll ask if
they want to put this up somewhere.
The problem with running a rt3 backport is that woody still has perl
5.6, which causes problems with international characters with rt3.
Anyway, that’s what I remember from this list (I am unfortunately not
in charge of any rt3 installation at the moment).
Greetings
Marc
Marc Haber | “I don’t trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things.” Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Which is what I’ve done (db on woody). Also, Thanks to the excellent
design of RT, and the superfurryanimal powers of debian, it was
possible
to quickly change front ends (s/sid/sarge/g) with no hassle. (i.e
migrate local hacks etc).
Which is what I’ve done (db on woody). Also, Thanks to the excellent
design of RT, and the superfurryanimal powers of debian, it was
possible
to quickly change front ends (s/sid/sarge/g) with no hassle. (i.e
migrate local hacks etc).
…you haven’t seen the cows in this part of the world then…
:-)On Tue, 2004-06-01 at 11:43, Nate Duehr wrote:
On May 31, 2004, at 2:16 PM, jamie baddeley wrote:
Which is what I’ve done (db on woody). Also, Thanks to the excellent
design of RT, and the superfurryanimal powers of debian, it was
possible
to quickly change front ends (s/sid/sarge/g) with no hassle. (i.e
migrate local hacks etc).
Bradley Bell wrote:> On Mon, 2004-05-31 at 16:43, Nate Duehr wrote:
On May 31, 2004, at 2:16 PM, jamie baddeley wrote:
Which is what I’ve done (db on woody). Also, Thanks to the excellent
design of RT, and the superfurryanimal powers of debian, it was
possible
to quickly change front ends (s/sid/sarge/g) with no hassle. (i.e
migrate local hacks etc).
In my honest oppinion you should not use neither Debian Testing(Sarge)
nor Unstable(Sid). And if you “upgrade” to Sarge/Sid lock your system
and only update critical security related patches. If you continue to
upgrade Sarge/Sid you will stay on the bleeding edge, and you will run
into problems with broken packages. And if you run into broken
dependencies you need somewhat more knowlegde than the normal Debian
sysadm to correct the errors. Remember that both Sarge and Sid is beta
software (No offence).
If you wish to stick to Debian, consider using backported applications
(see http://backports.org, http://apt-get.org or people.debian.org/~ sites). You will however run into some
problems conserning mod_perl and perl versions, but it’s quite easy to
resolve.
And there’s one more no-go. Don’t install Sarge/Sid packages into Stable
unless you know what you’re doing. It backfires over time.
I’ve just been through this. Sid broke twice in one week, and currently
remains broken.
I cannot confirm this. My sid systems are alive and kicking.
There was some mod_perl breakage recently, and if you’re running RT3
on top of Perl, this can be quite painful.
I have to disagree on that. priority high only shortens the wait
period. If a package’s dependencies cannot be satisfied in sarge, the
package doesn’t migrate to sarge even if the waiting period is over.
That way, a security update can be held from migrating to sarge for
weeks or even months.
This is correct, that’s why you have to become familiar with the build
process of the most important packages you use. Train using dpatch
and friends in advance, so that you can create your own security
update if necessary. Subscribe to the package tracking system for
your important packages. Follow the upstream announcement mailing
lists for those packages (sarge/sid vulnerabilities are not
necessarily announced by Debian).
And, what’s probably most annoying: regularly update to the most
current sarge or unstable version. This can be disruptive, and you
don’t want to add this to the usual troubles of a security upgrade.
