CentOS 6
Also, my existing linode is in Dallas. I would like to purchase a second, and I would prefer they be at the same facility because they will be communicating with each other, no need IMHO for that bandwidth to leave the data center.
Can I specify my new linode to also be at Dallas?
12 Replies
Communication between them will be minimal, and when I start to get near 80% of allotted bandwidth I know it will be time to open a new linode anyway, but yes - if there is a private network setting that lets me save on allotted bandwidth it is definitely worth checking out.
Doesn't look like v6.0 is getting ANY updates (and it's unclear if that's about to change, or if all work is being done on getting v6.1 out).
@vonskippy:
Doesn't look like v6.0 is getting ANY updates (and it's unclear if that's about to change, or if all work is being done on getting v6.1 out).
That seems like it. 5.6 got a continuous release repo to get updates from 5.7, but I don't see something like that for 6 (wasn't announced anyways), and there are no updates for 6.0/6.1.
It looks like the CentOS team has lagged too much with preparing 6.0 and now they can't catch up with RHEL anymore. 5.7 is coming, 6.1. When those come out there will be 6.2 and probably 5.8, and 4 is still alive; they again won't have enough time and power to manage both…
One thing I did on CentOS 5 - I would watch for RHEL CVE alerts and grab the RHEL src.rpm for the patches.
I'd then apply the patch to the CentOS src.rpm and release version it so that when the official patch from CentOS came, it would replace mine, but I would have at least have a patched package while I waited.
Patched package may not be 100% binary compatible (that's part of what slows down CentOS releases, RHEL uses a closed a build system and CentOS has to do some investigative work to make sure their build system produces something that really is binary compatible) but it would have the CVE closed.
@FunkyRes:
Continuous Release repo looks like a really good idea.
Depends what for. For personal stuff, or a dev box, or many other things, sure. For a production box, never.
@Guspaz:
@FunkyRes:Continuous Release repo looks like a really good idea.
Depends what for. For personal stuff, or a dev box, or many other things, sure. For a production box, never.
Continuous release between major versions, I agree. But in RHEL land a dot release does not perform major updates.
When a dot release is released, yum will update you to the next dot release anyway, and updates to the previous dot release halt.
Since CentOS lags behind rhel, this means that bug fixes (including security fixes) don't get pushed to the CentOS users until CentOS catches up with the RHEL dot release. This is bad, and why on CentOS 5 I would watch for CVE's on RHEL and roll my own updates if it looked like an exploitable bug.
With a rolling update repository, we would not need to wait for CentOS to finish mastering a specific dot release in order to get updates to known bugs and security issues.
That is why this is a good thing.
Of course any production machine should have updates disabled so they can be tested on a dev box before applied, but that should be done regardless of a rolling update repository.