Outdated distros ?
Some of those generic default distros are sorta old by now. And some of the contain multiple OpenSSH/OpenSSL exploits. Which only make them insecure for the customer and possibly the host (Worm eating the CPU, IO) by default as well.
(IE: Linode's Mandrake is at 9.1, when Mandrake 10 has been out and so far 99.999% of the public really really really like the new release, etc. Same with the newer Slackware 9.1)
Obviously something needs to be done about this. I think that either Caker creates new images, or we the UML-experienced users be allowed to create "community distros".
In all honesty I'm for the latter simply because someone in particular is going to know a bit more about whatever popular distro there is. Yet at the same time, I fully understand the legal issues invovled in having extermal contributors to such a product/service. (maybe we could sign a legal agreement/NDA/etc)
However the above issues shouldn't be used an excuse to limit the number of distros. I'm pretty sure that multiple distros is is a major selling point for those who (ie: me) have an immense distaste for RedCrap/Fedora that other not-so-cool VPS/VDS providers offer.
Like I said, just some random thoughts …
There is one thing I will say: All distro images should be "small" by default. The reason is because such distro images are going to have less running on them, and therefore going to have less security issues by default as well. (Obviously I'm borrowing from OpenBSD's mantra.) Additionally, being that linode's target customer are technical people (and not mindless people), they should have zero issues installing what they desire on their own. (more OpenBSD mantra, heh)
Bill Clinton
(real life: Sunny Dubey for those of you new to the board)
PS: SuSE's YaST2 will become GPL. (or it already has?) Which means this could easily be a new distro option for Linode!
5 Replies
@Bill Clinton:
Some of those generic default distros are sorta old by now. And some of the contain multiple OpenSSH/OpenSSL exploits.
Obviously something needs to be done about this.
apt-get update && apt-get upgrade
Works on Debian, and on Fedora.
> I'm pretty sure that multiple distros is is a major selling point for those who (ie: me) have an immense distaste for RedCrap/Fedora that other not-so-cool VPS/VDS providers offer.
We don't need distro flamewars here. What's wrong with Fedora, anyway? I've set up a Fedora system for my employer, and I'm finding that I really like it - the convenience of apt-get (or yum) and I've always found RedHat-style systems a bit easier to configure than Debian.
My own personal Linode runs Debian, but may go to Fedora soon.
The Gentoo image seems to be perfect as it is, with the possible exception of caker's decision to defile it through vi contamination.
@myrealbox:
FWIW, the Gentoo distribution seems to be based on 2004.0, not 1.4 as its title suggests.
Realistically, these numbers mean jack. The number refers only to the version of the LiveCD that Gentoo ships (or you can download). By the time caker actually posted the Gentoo image the first time around, it wasn't even "1.4" anymore, because he had run an emerge update.
Now, it's nowhere near close to "1.4", but again it's not "2004.0" either, since he just updated it with emerge (I believe). Actually, I do believe that the Linode Gentoo image was created using the 1.4 LiveCDs, so technically, the number is close. In Gentoo, there is no frozen numbered state of the system, running 'emerge -u world' will always get you to the exact point of the latest releases. (The packages included in 1.4 or 2004.0 aren't anymore stable than any other per se; it's just a snapshot in time).
But I have requested to caker that he remove the number entirely, since it does nothing to inform anyone what the state of the Gentoo image really is (and now it does even less since the number is so outdated). I requested that he label them "Gentoo Linux [2004.03.17]" with the date being when he last updated the packages in it. If that's not acceptable, then just "Gentoo Linux" would be more accurate…
just my two cents…
-j
p.s. Is there really no cron daemon included? I've never noticed, but will admit, never really checked!
This shouldn't require a very frequent update on the images, especially the minimalist ones, since major security holes are rarely discovered on the very core packages like fileutils / glibc etc.. OpenSSH would be one to be very vigilant about, though.
This way, newcomers who have just rolled out a brand new distro image gets a somewhat secure installation by default, instead of having to scramble to do an immediate update before the next wave of portscans hits.