What's with all the FUD? I just ran 'yum update' on my VPS (6.4 -> 6.5) yesterday without any hassle at all. It doesn't just start downloading things out of the blue you know, it'll check first what packages are available and then ask what you want to do. If you have broken packages, you can skip those with --skip-broken flag, of which it will remind you if you have them!
Worked like a charm.
Your upgrade process is often a reflection of your installation process: if you were uncareful and skipped over details, such things have a tendency to bite you in the rear. E.g.: Don't mix repositories offering the same software but with different configurations, like clamav, or you will have a bad time. This was one of my stumbling blocks, but I learned from it.
When upgrading major versions eg from 5.x to 6.x, I agree that a reinstall is probably more apt.
It's people speaking about things they know little to nothing about. For example referring to apt as superior to yum because major release version upgrades using yum is not recommended. This ignores that:
- It's not talking about what they think it's talking about. 6.4 to 6.5 is a minor, or point release, and is fully expected to be updated using yum.
- Even if it was a problem, that would be a problem mostly of the package format (rpm vs deb) and what it supports or how they were created by the maintainers, not the tools that take the packages and use them to determine dependencies and apply the updates.
- The package formats are similar enough in capabilities that the package managers can actually handle repos of the other packages. You can get apt on CentOS, and yum on debian based systems, and use them on the native packages with a little work.
RHEL really is a best of class distro, and just because they've focused less on swizzy-look-cool features doesn't mean they've been resting on their laurels. They've invested a lot in making sure the distro works well in their entire ecosystem of products, and just plain works without too many problems. In a way, they are the Microsoft of lniux distributions, in that they have a solution for just about everything, and it just works most the time. In a way, it's the best of both worlds.
TRIM Support in mdadm:
The mdadm tool now supports the TRIM commands for RAID0, RAID1, RAID10 and RAID5.
Full Support of fsfreeze:
The fsfreeze tool is fully supported in Red Hat Enterprise Linux 6.5. The fsfreeze command halts access to a file system on a disk. fsfreeze is designed to be used with hardware RAID devices, assisting in the creation of volume snapshots. For more details on the fsfreeze utility, refer to the fsfreeze(8) man page.
How do you handle filling the disk? If my storage is 50% utilized, and 10% of that data changes every month (assume 10% of the bytes change if that makes it easier), what happens after 10 months?
If you mean it took less time for CentOS to push out 6.5 from when Red Hat released their 6.5, this may be because of sponsorship allowing the maintainers to spend more time, and because of improved build processes.
CentOS Devel archives worth a look sometimes as is Karanbir Singh's blog.
I use CentOS stock desktop on a recycled laptop as a writing machine. Just the Fluendo mp3 decoder, Adobe Flash installed from RPM and the ntfs-3g package from RPMFusion downloaded and installed so I can read NTFS external hard drives. It all just works on the X200s, including hard drive encryption as I get email on this machine and don't want data accessed if it gets stolen or lost.
The 6.5 update just came through as a regular update although much larger than usual (350Mb of download) this morning UK time. All solid, no problems. I always find it amusing that Linux based OSes can run an upgrade like this while I carry on typing in homework questions!
Just don't forget that the official stance is that a fresh install is preferred to an upgrade for RHEL/CentOS. I'm sure for your purposes it's fine, but just a heads up.
(I manage a handful of CentOS boxen and have found this out the hard way.)
6.4->6.5 is a minor update. yum update, reboot that is all. Just works. Done it, thanks to ansible, to 24 machines today in about 30 minutes after I QA'ed the packages on my staging machine, DO droplet and laptop.
Between 6.x and 7.0 is another story and I wouldn't do this with any distro. Risk is too high. Just build new kit, test it then migrate services and data over piecemeal.
Debian screwing up dovecot configuration terribly between 6 and 7 is a fine example of why you shouldn't do this.
I've managed about 60 CentOS/RHEL machines, 30+ Debian machines, 20 FreeBSD machines and 200 Solaris machines and I've never done a major release in place upgrade.
And you can take the reboot as a very strong suggestion, depending on your needs and whether there are kernel exploits to worry about (Oracle's purchase of ksplice is yet another reason I hate them). Much of the time (on select systems!) I get away with just restarting the services. Reboots really do bring peace of mind though.
Well I'm not sure it has anything to do with vulnerabilities or not. They do a large feature add on minor updates between 6.x and 6.x+1 which may or may not add new modules etc.
I design stuff to be resilient to host reboots. Then again we have a lot of kit to play with.
Nope. I only run non critical stuff on DO like my personal email and web which to be honest I don't care if someone cracks or breaks. Once I've changed my ISP I'll move it all in house and use an old ThinkPad as a server (built in UPS and console!). We have colo dedicated kit and VMWare (die!) for the production stuff - it's the only way.
DO turn SELinux off on their kernels and take ages to update so I can't really take them seriously for production to be honest. Also they appear to be VC backed which is usually a sign of shortcuts taking priority over proper due diligence.
Then again for $5/month, pay peanuts, get monkeys. Not bad monkeys for the money. I've paid 3x the amount and got worse monkeys.
As others have said, my understanding is that deltas within a major release are upgrades. In fact I have upgraded from 6.3 to 6.4 and now 6.4 to 6.5, but had to re-install this machine to enable hard drive encryption.
The 6.3 -> 6.4 and 6.4 -> 6.5 updates arrived simply as software updates using the usual process just involving the download 340Mb of files. I gather the 6.x designation relates to updating the installer and packages available on the release DVDs
I think you are referring to 5 to 6 and ultimately 6 to 7. Major versions.
Unfortunately upgrading between major releases on CentOS/RHEL is very problematic and it's advised to do reinstall (!). Where on deb based distros it's just dist-upgrade. Recently I've tried CentOS on my work laptop, and managing software with yum is just plainly broken compared to apt. Multilib problems, excluding rpmforge repo conflicting with epel, etc, etc. For example I didn't find the way to compile qtlandcarte, it was just impossible to find required packages. Apt I must say is ages ahead yum. Even using nix for additional packages didn't solve all problems. But on the other hand I use CentOS on dev/test/QA servers for RHEL compatibility and I'm very happy with it.
Unfortunately upgrading between major releases on CentOS/RHEL is very problematic and it's advised to do reinstall. Where on deb based distros it's just dist-upgrade.
Nowhere does anyone advise to reinstall. Can you quote your source please.
managing software with yum is just plainly broken compared to apt.
You're trolling. How is it broken?
Multilib problems
Trolling again. Which problems?
For example I didn't find the way to compile qtlandcarte
Ah okay. So you're asking for help. Well, what was the problem?
>Nowhere does anyone advise to reinstall. Can you quote your source please.
I guess other replies cleared that for you.
>managing software with yum is just plainly broken compared to apt.
>You're trolling. How is it broken?
for example installing something which has certain library requirement, updates repo provides new library version but not this package (--skip-missing? please), other repos (not exactly yum fault) providing same versions of software but with different prefix in name causes problems with overlaping locations of files etc
>Multilib problems
>Trolling again. Which problems?
I remember having hard time with Virtualbox and qt 64 and i686 in 6.4
>For example I didn't find the way to compile qtlandcarte
>Ah okay. So you're asking for help. Well, what was the problem?
No, it was example. Problem was, with lower versions of libraries or none at all (gdal, Proj4), which leads to using "other repos" which ends with see above.
>Apt I must say is ages ahead yum.
>Trolling again. Say how it is ages ahead.
Well literally apt 1998 yum ~2003, but also try to package perl modules with each for concurrent two different versions of perl, or do the same with python, and apt/deb saves you a lot of time.
This above as I stated in my first post is mostly valid for desktop/dev usage, for server use I'm very happy with RHEL/CentOS.
From the big fat warning box at the top of the page:
> Red Hat does not support in-place upgrades between any major versions of Red Hat Enterprise Linux. A major version is denoted by a whole number version change. For example, Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6.5 are both major versions of Red Hat Enterprise Linux.
I gave the poster the benefit of the doubt since they offered with the dist-upgrade comparison which one would only need for major release upgrades. The yum and library complaints however I didn't want to touch since I haven't experienced that with CentOS/RHEL.
You're confusing two things. It's not suggested to go from, say, CentOS 5 to 6 in place. However, going from 6.4 to 6.5 is expected.
Edited to add: per the release notes, emphasis mine: "Similar to the practice of the upstream vendor, there is no supported path to 'upgrade' an installation of a prior major CentOS release (presently CentOS 5) to a new major release."
*. RHEL 6.0 to CentOS 6.0: 242 Days
*. RHEL 6.1 to CentOS 6.1: 204 Days
*. RHEL 6.2 to CentOS 6.2: 14 Days
*. RHEL 6.3 to CentOS 6.3: 18 Days
*. RHEL 6.4 to CentOS 6.4: 15 Days
*. RHEL 6.5 to CentOS 6.5: 10 Days
I know i will piss a lot of people of by writing this.
But CentOS feels like ruby stuff. Stuff may work but probably not cause you used wrong version of bundler or some random dependency wont work.
Every change becomes a major hassle.
Point proven by the fact that no one thinks upgrading from 6.4 to 6.5 is even an option if you don't do a clean install it's your own fault if stuff wont work.
> no one thinks upgrading from 6.4 to 6.5 is even an option
OMG, who tells you this? They should not be allowed anywhere near a computer. Do yourself a favour and stop listening to them. Seriously.
Actually one of RHEL's strong points is that you can easily do updates between minor versions and it will still work, even after 10 years.
Yes, nothing is perfect and every now and then shit happens, but quality wise RHEL (CentOS too!) is still in a class of its own.
You have a problem? Search the interwebz, get on the forums, on the mailing lists, you're not alone.
No one said that update from 6.4 to 6.5 needs clean install. I just did this yesterday without much thinking... just "yum -y update". I must admit though, I don't have much installed, but in past I had the same experience... from 6.2 to 6.3 and so on...
Yeah it's not like any major corporations make their living offering enterprise support on a practically identical distribution. Who's saying this stuff? I've upgraded many servers through minor revisions of CentOS and never had any big problems that weren't my own fault.
Yeah, it was so hard. I was getting pretty tired before I could finish typing 'yum upgrade' on the terminal, and then I had to wait a whole twenty seconds for it to resolve dependencies, reach all the way to my keyboard to hit the 'y' key and hit enter, and then it took like five minutes to download and install everything.
Worked like a charm.
Your upgrade process is often a reflection of your installation process: if you were uncareful and skipped over details, such things have a tendency to bite you in the rear. E.g.: Don't mix repositories offering the same software but with different configurations, like clamav, or you will have a bad time. This was one of my stumbling blocks, but I learned from it.
When upgrading major versions eg from 5.x to 6.x, I agree that a reinstall is probably more apt.