Our web servers run Debian for the most part. The only real hassle has been with PCI-DSS compliance. For example, Debian Squeeze has Apache v. 2.2.16 (or did until recently), which our compliance scanning vendor flagged as having several unacceptable security holes.
The solution that's worked well is to just selectively upgrade the handful of offending packages: either from testing, or some other source, or in rarer cases, compiling from source. Annoying and time-consuming, but soluble, and IMO worth the tradeoff given Debian's other good qualities right now.
Your scanning vendor should know better and advise you properly. Just kidding, the "security" industry sucks.
Debian and other long term enterprise distributions backport fixes for these unacceptable security holes. A better solution is to simply turn off the minor version string as that's the extent of their testing.
I'd guess a good number of people intuitively do what you did. The problem is, instead of getting sucked in by a scheduled apt-get update, now you probably wont notice critical fixes until the next quarterly scan is due.
I was thinking "Hasn't it always been?", and then remembered Redhat.
Debian shows that actually solving real problems well is a valid way to approach open source software over the long term.
I first got into Linux years ago, before Ubuntu really existed. At the time, Debian was really awesome. It solved the biggest problem at the time: installing, updating, and removing software on *nix systems.
By contrast, Redhat had rpms, but they sucked. I still, to this day, have a difficult time figuring out how to do /anything/ with packages on anything derived from redhat. What is up2date? what is yum? where does the rpm command it? why aren't all of these documented well?
I think ultimately the rise of Debian illustrates the conflict of interests that comes from certifications. Making your software easier to use makes certifications less valuable, after all.
I haven't used RedHat-based distros for years now but I remember that back when I switched to Debian-based distros I was equally confused about Debian's package management system. I didn't think, and still don't think, that dpkg and apt are documented that well. To answer your question: yum is to rpm as apt is to dpkg. But I've always found it weird that there's a difference between apt-get and apt-cache; in contrast, "yum install" and "yum search" use the same executable. The documentation concerning building Debian packages is often out of date and scattered all over the Internet with no clear central place. And finally there's this "aptitude" thing; I still don't understand why it exists and how it's different from regular apt.
>And finally there's this "aptitude" thing; I still don't understand why it exists and how it's different from regular apt.
Aptitude is a APT frontend that solves exactly the problem you mentioned; no more `apt-cache search` nor `apt-file`, it's all just `aptitude`. Plus a little bit of dependencies tracking (which I think apt has it available for a while already). aptitude is exactly what apt should be, IMHO.
Basically my experience with Debian long ago as well. I have always thought the Debian packaging system was far superior to rpm and was glad to see Ubuntu take the Debian experience and bring it to the masses (although I still prefer straight up Debian for myself)
I started with Debian because I perceived it to be the safest. As I became more comfortable with Linux, I became frustrated with the versions available to me through apt-get of software that I wanted, and I rapidly became tired of compiling everything I wanted from source in order to get a more recent version. I finally took the chance on Ubuntu for that reason, and haven't looked back. I suspect my story is a common one.
I'm not sure it is. Speaking only from personal experience, we've canned all our Ubuntu LTS machines as they were terribly unreliable (kernel failures and wierd bugs on good hardware) and shipped broken packages regularly (mysql-server being the most notorious).
Every 6 months, Ubuntu grabs the latest packages from Debian unstable. In contrast, it usually takes two years for new versions of software to move from Debian unstable to testing to stable.
Though I made the switch too, I don't get your problem with packages. Debian uses Aptitude same as Ubuntu. It sounds like the problem you had with Debian was that you didn't have the sources you needed in your sources list.
I started with CentOS but found it difficult to maintain and set up. Then I switched to Debian because for some reason I felt pressure to not use Ubuntu. People often imply that Ubuntu is for bad programmers, inexperienced people, etc. It's kind of like "well, all the cool kids are using distro X because we're l33t and you're not cool because you use Ubuntu" so I stayed away from it for a while. Finally I ended up deciding that it was more important to just get a fucking app running on a server I could most effectively use. I'd been using Xubuntu and Crunchbang on my laptop for a while and so I made the switch and I'm very happy with it. I subsequently redeployed all my VPSes with Ubuntu 11.10 or 10.10 depending on what the hosts offered. I like it because not only is it the easiest for me to manage but it seems like its easier to find help for any problems you may run into and good documentation.
I say screw the hipster crowd who are too cool for Ubuntu and just focus on what's best for you. I think people like that are trying to convince themselves of how great they are more than anything else.
>Finally I ended up deciding that it was more important to just get a fucking app running on a server I could most effectively use.
Be a l337 hipster with your desktop if you must, but for servers go with what has had the most man hours put into its evolution toward stability, performance, support (aka, it just works). In that regard, if Ubuntu is good enough for Facebook's servers (I hear, but haven't verified) it's good enough for mine.
Right. I've tried other distros and I'm just not comfortable enough with them. There's no shame in being inexperienced at something. Ubuntu makes my life easier so I use it. If I grow out of it one day (which I really doubt) then I'll switch but it makes no sense forcing yourself to use something you don't understand because someone thinks they know what's best for you.
I believe I could have perhaps, hacked the sources list, but the 'correct' debian sources for a given package are often a version or two behind the Ubuntu sources.
This is a desirable trait in a server. You keep behind everything by a version or two and you are essentially guaranteed more stability. Considering how Ubuntu 11.10 has run on my desktop, I would not want to build my business off it.
Mot vendors offer a PPA for easy integration with apt on debian. MongoDB, Maria/MySQL/Percona etc. This way your core system stays solid and well tested, but you can build your app layer using whatever version you want. It's definitely a win-win.
They say that Debian servers come from new servers, and many subsequentially change to Ubuntu. From the graph it's clear that CentOS and Debian is mostly steady, Ubuntu is on the rise and everything else is on the way down (in percentages of course).
I'm curious because I don't follow server distro updates often: what server-side stuff did Ubuntu improve on? I was under the impression that most of their gains were on new user experience as opposed to traditional administration.
They have created Screen, and they have a lot of Cloud tools they've created based on Openstack. They also have some better default service configurations. [citation needed].
Canonical did not create screen; it is a GNU project that existed before Ubuntu ever did. They did, however, develop an extended, improved version of it (byobu).
It isn't really a "version" of screen. It is a bunch of scripts and wrappers using/around hooks that screen had built in (but hardly anyone ever knew existed).
It is a rather nice little set of basic improvements though.
No, you could not.
Afaik Ubuntu releases don't correlate that much with Debian releases.
CentOS on the other hand is always binary compatible and basically just a re-branding of RHEL without the commercial support.
So, apart from the commercial side CentOS and RHEL are pretty much exactly the same.
I don't beliebe this is true for Debian and Ubuntu.
As far as i know, it's like that: Fedora is the bleeding-edge Desktop RedHat version that gets the latest stuff. At some time it's forked, fixed and baked into a RHEL release. When this is released it's taken by the community, recompiled/branded (with the exact same sources) and released as CentOS.
Expect this to be brief. For a while, there was uncertainty because CentOS updates were way behind Red Hat (the upstream vendor). As of January, CentOS is effectively in sync with RHEL.
It definitely is. The upgrade path between major versions is significantly easier which is where it really hurts. Also, despite the Debian packages being a little older, they always just work and have sensible patches and defaults applied.
I'm not sure there are many completely objective reasons to choose one or the other. Things like release-cycle style and package layout come to mind. CentOS also has a different toolchain for some system management tasks like run-level management. Keep in mind that for everything you like about Debian, there maybe someone else who dislikes it. For example, some sysadmins would rather the Apache 2 package not create folders like sites-enabled/sites-disabled along with the associated tools.
Quite right, I seriously dislike the scattered approach to configuration files of Debian packages and thus I stay clear of Debian and any derivative like Ubuntu.
However the end result is the same, a properly configured a Debian box works just as well as a properly configured CentOS or Arch box.
Some packages are more stable or up to date on CentOS than on debian, java, virtd and xen comes to mind. When I used the packages on Debian I needed to do some tweaking whereas on CentOS these things worked out of the box.
I got this idea that in general Debian is easier to manage but for all the 'Enterprizy' stuff CentOS has the edge.
The solution that's worked well is to just selectively upgrade the handful of offending packages: either from testing, or some other source, or in rarer cases, compiling from source. Annoying and time-consuming, but soluble, and IMO worth the tradeoff given Debian's other good qualities right now.