Professional Web Applications Themes

Debian and security/bugfixes/errata - Linux Setup, Configuration & Administration

I'm one of many RedHat orphans looking for a new home now that support for my old RH 7.3 distro is ending at the end of the year. I'm trying to find a new distro to replace it, and I'm mainly eyeing Debian and Fedora. The box we're running is a mainly an e-mail, web, and RealAudio server. For that reason, a lot of the bells and whistles that come with most distros (this box will probably sit in a corner and never run XWindows at all), but I probably want enough newer features (including a 2.4 kernel) that if ...

  1. #1

    Default Debian and security/bugfixes/errata

    I'm one of many RedHat orphans looking for a new home now that support for
    my old RH 7.3 distro is ending at the end of the year. I'm trying to find a
    new distro to replace it, and I'm mainly eyeing Debian and Fedora.

    The box we're running is a mainly an e-mail, web, and RealAudio server. For
    that reason, a lot of the bells and whistles that come with most distros
    (this box will probably sit in a corner and never run XWindows at all), but
    I probably want enough newer features (including a 2.4 kernel) that if I'm
    going to go with Debian, it will probably be the "testing" (sarge) release
    rather than "stable" (woody).

    One of the biggest factors for picking a distro for our situation will be
    will be timely bugfixes and security patches.

    I'm familiar with RedHat's up2date system, and it seems like they've
    generally been pretty good getting patches and fixes done within a day or
    two of an incident report. I wonder if someone could tell me how Debian
    handles security patches.

    Specifically, if I understand their website correctly, security patches are
    first done for "stable", then applied to "unstable" as time and resources
    permit. When do patches get applied to "testing"? Pretty quickly? Or only
    after they've been in the "unstable" release for a while?

    To put it another way, if another OpenSSH vulnerability is discovered and
    I'm running "testing", how long would it take before an updated package
    would be available for downloading and installing?

    And if timely security patches are important to us, should I be using a
    different release? Or a different distro altogether?

    Thanks to anyone who can help!




    George Guest

  2. #2

    Default Re: Debian and security/bugfixes/errata

    In article <newsguy.com>, George Adams wrote: 

    Don't jump to conclusions. The Woody install disks (3.0r1) come with
    a 2.4.18 kernel with security fixes since then backported.
    And if you don't like that, you can always build your own.
    Most of my Woody boxes are running 2.4.22. I don't bother to
    "debianize" my kernels because I don't distribute them.

    Woody 3.0r2 will be released this week.
     

    Then I think your best choices are Woody and OpenBSD.

     

    It's equally timely.

     

    Woody is a production system. It gets security updates right away.
    A lot of the packages are based on quite old versions of the "upstream"
    sources (PHP and KDE are ancient at this point...) but the maintainers follow
    the upstreams and backport any security updates.

     

    It seems to me we always get OpenSSH updates within two days of the
    announcement.

    Testing is not a production system. If you care about stability
    and reliability and security, you should not use testing.
    You can't even be sure it will install on any particular day.
    For a server like the one you described, testing would be a mess.
    If you really need an up-to-date PHP, it would be easier to
    just use the upstream for that one product.
    A few days ago, I built Apache 2.0.48 and PHP-4.3.4 on Woody just to see
    if they would work. It only took a few minutes and they work fine.
    But I still run Debian's Apache 1.3.26 (+ fixes) on the server that matters.

     

    Once you get used to apt-get you'll wonder how you lived without it.
    Woody (aka "stable") is the way.


    Cameron


    Cameron Guest

  3. #3

    Default Re: Debian and security/bugfixes/errata

    George Adams wrote: 

    I'd strongly suggest using Debian/stable rather than testing in that
    situation.

    Why exactly do you feel you need testing? The only thing you
    specifically mention is a 2.4 kernel. Debian/stable offers 2.4.18.
    Plus stable has all the timely security updates you'd need on a server.

    BTW, there's absolutely no reason you can't run your own kernel. My
    server & firewall boxes all run Debian/stable with custom 2.4.22 kernels
    I compile myself from the vanilla kernel.org sources. It works
    flawlessly.
    John-Paul Guest

  4. #4

    Default Re: Debian and security/bugfixes/errata

    Thanks for the reply, Cameron. I'll give woody another look, though you're
    right in assuming we'd probably need more recent versions of Apache, PHP,
    etc. Which brings up a question:
     
    matters.

    During the first few months of my using RH 7.3 (and later 8.0 and 9.0), I
    installed custom-compiled versions of Apache, PHP and a few other things and
    uninstalled the default RH RPMs for those packages. This worked out fine,
    until security issues became more of a problem. A vulnerability in, say,
    OpenSSL suddenly meant that I had to recompile Apache/mod_ssl, PHP, and
    whatever else I had that depended on certain SSL libraries. I eventually
    decided to do away with my custom-compiled programs as much as possible,
    re-installed the RH RPMS, and let "up2date" take care of the patching for
    me.

    i.e. when I had to decide between "newest features but manual maintenance"
    vs. "older version but automated updates", I usually went with the latter.

    Would the process (and drawbacks) of installing custom programs on Debian be
    the same? i.e. if I decide that I just have to have features x,y, and z in
    a newer version of PHP that woody doesn't have, am I going to have to just
    resign myself to doing the manual recompile/reinstall thing that I did back
    in my old RH days?

    If that's true, and if (as you say) woody has a number of very stable,
    secure, but "ancient" programs, then I may end up having more programs I
    have to maintain by hand than I did back with RH.

    Thanks again.



    George Guest

  5. #5

    Default Re: Debian and security/bugfixes/errata

    ["Followup-To:" header set to comp.os.linux.misc.]

    On 2003-11-18, George Adams <com> wrote: 

    This may be the impression you get from http://www.debian.org/security/faq,
    but that describes the work done by the security team. In practice,
    usually the regular Debian maintainer will upload a new version to unstable
    in a timely way.
     

    A package can be moved from unstable to testing in two days IF it is marked
    "urgency: high" AND satisfies four other criteria related to bugginess and
    overall distribution consistency:
    http://www.debian.org/devel/testing
     

    It could take weeks and weeks if, for example, the new ssh depends on
    libraries that are not ready to be moved into testing.
     

    Certainly you should not be running testing; no one should recommend that.
    You could run stable+security patches, or unstable, or a mixed
    testing+unstable system taking advantage of features like apt_preferences
    (not everyone likes the preferences doentation, but at least there is a
    man page in section 5).

    --
    Paul Kimoto
    This message was originally posted on Usenet in plain text. Any images,
    hyperlinks, or the like shown here have been added without my consent,
    and may be a violation of international copyright law.
    Paul Guest

  6. #6

    Default Re: Debian and security/bugfixes/errata

    George Adams writes: 

    Rather than fetch the upstream source and build and maintain the program by
    hand you should fetch the Debian source package from Unstable and backport
    it. In most cases this is quite painless.
    --
    John Hasler
    gt.org (John Hasler)
    Dancing Horse Hill
    Elmwood, WI
    John Guest

  7. #7

    Default Re: Debian and security/bugfixes/errata

    George Adams wrote: 

    I'm a Red Hat refugee, too, and a Debian newbie because of it. So
    take what I say with a grain of salt. <grin>

    First, you can use a technique called "apt-pinning" to run selected
    packages from testing or unstable, but with most packages from stable.
    Google "apt-pinning" for details.

    Sometimes it doesn't work, though, if a package was compiled to
    require, for example, a higher version of glibc than what's in stable.
    In that case, I've found it's fairly easy to say

    # get build requirements from testing
    apt-get -t testing build-dep randompkg

    # get source from testing and build it
    apt-get -t testing source -b randompkg

    # install newly built package
    dpkg -i randompkg*.deb

    Note that in both cases you'll have to pay extra attention to
    vulnerabilities in the package you install either of these ways, since
    you won't be receiving "stable" level updates to them. But that's
    also true if you roll your own from the upstream source, and it's not
    nearly as easy.

    If I'm completely out of line with what I've said, I hope someone who
    knows better will correct me. <grin>

    Ed

    Ed Guest

  8. #8

    Default Re: Debian and security/bugfixes/errata

    George Adams wrote:
     

    *SNIPPED*
     

    Another avenue not really discussed yet is "backports". There are a number
    of repositories that have ported the newest versions of software so you can
    install them on a standard Woody machine. I run several Debian production
    machines running Woody with backported PHP-4.3.4, MySQL-4.x (can't remember
    the sub version) etc. Most of my backports come from
    http://www.backports.org/. They are timely with their bug and security
    fixes (less than 2 days for the most recent SSH bugs). No problems yet :)

    Backports are great because they integrate into Debian's normal packaging
    system without you needing to know whether it's a backport or a standard
    Woody package. You simply add the list of backport repositories to
    /etc/apt/sources.list then do "apt-get update" and voila - you're ready to
    install the new versions available in the repositories.

    FWIW, this laptop I'm writing on is Debian Woody with backported KDE-3.1.4
    etc and it has never missed a beat (or an update) :) YMMV

    --James
    __________________________________
    A random quote of nothing:

    A Parable of Modern Research:

    Bob has lost his keys in a room which is dark except for one
    brightly lit corner.
    "Why are you looking under the light, you lost them in the dark!"
    "I can only see here."

    Centurion Guest

Similar Threads

  1. "The Complete FreeBSD": errata and addenda
    By Greg Lehey in forum FreeBSD
    Replies: 8
    Last Post: April 8th, 05:02 PM
  2. [ANN] Syck 0.41 -- 95% Support, Bytecode, Bugfixes
    By why the lucky stiff in forum Ruby
    Replies: 0
    Last Post: October 14th, 08:35 PM
  3. Errata -Update
    By Kissi5559 in forum Linux Setup, Configuration & Administration
    Replies: 1
    Last Post: September 9th, 04:48 AM
  4. Debian/Testing and security updates
    By Greg Folkert in forum Debian
    Replies: 3
    Last Post: July 26th, 06:10 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139