Ubuntu as a server
Shot (Piotr Szotkowski)
shot at hot.pl
Sat Jan 28 16:53:47 UTC 2006
> On Sat, 2006-01-28 at 05:52, Shot (Piotr Szotkowski) wrote:
>> Mike Bird:
>>> On Fri, 2006-01-27 at 03:33, Shot (Piotr Szotkowski) wrote:
>>>> Well, it depends, really. Trac, a valid universe package choice
>>>> for servers, has open security bug(s) for almost two months now:
>>> Just pin Trac to Dapper.
>> That’s not a good idea for the following reasons:
>> 1. trac is an *ubuntu*-versioned package,
>> so is not auto-synced with Debian.
> How does that relate to the issue of a Dapper pin?
If there was a security bug found in Trac now, Dapper might’ve not get
updated. Pinning trac to Dapper doesn’t take care of tracking trac’s
(or any other universe package’s) security support by hand.
>> 2. Dapper is past UVF, so it won’t see any unsupervised updates anyway.
> Dapper Trac already has the security fixes that the OP needs.
Yes, in case of the *current* fixes for *Trac*. It’s not an
universal approach for other packages and future fixes for Trac.
>> 3. From what I undestood from previous ubuntu-devel discussions, it’s
>> generally better to rebuild packages for Breezy than to take Dapper’s
>> binary packages, even if their dependencies are fulfillable in
>> Breezy (the same applies to taking binary packages from sid).
> Trac is written in Python. No binaries. Also I thoroughly
> tested Dapper Trac in Breezy before recommending it.
Great. I’m writing about the general approach to backporting universe
packages (for security fixes) and why simple pinning to current-stable+1
is not enough; trac was just an example of an universe package that’s
useful on servers.
> How much testing did you do before posting to this list where your
> "not a good idea" post will be misleading people for eternity?
>> Given that rebuilding a package is usually as easy as downloading
>> the orig, diff and dsc fies, doing `dpkg-source -x *.dsc` followed
>> by `fakeroot dpkg-buildpackage` (split by a `dch` step for those
>> who like to have packages versioned properly), I’d rather stick to
>> rebuilding either Dapper or sid packages.
> You forgot the tricky part - pinning to Dapper or using something
> like FTP so you get the correct (Dapper) source to build.
What’s tricky in getting the orig, diff and dsc files?
They’re even linked from the source package’s page.
> Please upload it to backports and let us know when you're done.
I don’t have upload rights and I’m not building the packages for general
use (in a clean chroot, with proper testing, etc.), so I doubt my builds
would be useful to anyone.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ubuntu-users