CentOS 7 potential release

CentOS 7 potential release(seven.centos.org)

45 points by lpinca 11 years ago | 55 comments

ck2 11 years ago |

Even this article title says "POTENTIAL" release. I am not even sure it is signed?

They are still doing QA, it will be a week or two before GA

Before you rush to 7.0 after 6.5 - things you are going to have to learn because they change everything:

   systemd replaces init.d
   grub2 replaces grub
   xfs is now default over ext4 filesystem

(many, many people dislike systemd, it is somewhat anti-linux in nature)

No more easy editing/understanding grub.conf

No more easy to edit/understand /etc/init.d (systemctl instead)

No more text log files for system log (journalctl instead)

Watch out for default XFS filesystem instead of EXT4 because it is slower in real world use for databases, etc.

Red Hat claims RHEL7 is 11-25% faster than RHEL6, I am not convinced at all, I think they are referencing a stock setup for 6 vs 7, but I don't know anyone that runs things stock without tuning. Wait for independent benchmarks.

CentOS 6.x will be supported until 2020

If you want a 3.x kernel for CentOS 6.x, try the ELrepo repository, they do builds for both mainline and longterm 3.x kernel releases. http://elrepo.org/tiki/kernel-lt

If you want newest GCC for CentOS 6.x try the CERN repo for devtoolset http://linux.web.cern.ch/linux/devtoolset/

ps. there is currently no way to upgrade a 6.x install "in place" to 7.x, though Red Hat has migration tool and CentOS folks say they will look at doing the same - but like I said, don't be in a rush to early adopt 7.x

pps. RHEL7 notes are a way to explore what else is new: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

nodata 11 years ago | |

No more easy editing/understanding grub.conf

True, the grub2 config is horrible.

No more easy to understand /etc/init.d

It's a bit more complicated, but not too bad:

Instead of "/etc/init.d/thing restart" you type "systemctl restart thing"

Instead of chkconfig --list, you type "systemctl list-dependencies"

Writing the equivalent script with systemd is much cleaner with less hacks, particularly for launching as different users and doing locking.

No more text log files for system log (journalctl instead)

By default. It's fine once you get the hang of the new syntax:

journalctl --since=today --follow

Watch out for default XFS filesystem instead of EXT4 because it is slower in real world use for databases, etc.

Depends on the workload. Speed is only one part of it. For some benchmarks by phoronix see http://www.phoronix.com/scan.php?page=article&item=linux_315...

ck2 11 years ago | | |

I'll wait for more benchmarks to be certain but this database test of the 3.10 kernel (which 7 uses) of XFS vs EXT4 is not promising:

http://openbenchmarking.org/prospect/1305166-UT-FILESYSTE20/...

lotsofcows 11 years ago | | |

systemctl: I don't think anyone cares about a change of command name / syntax, it's the removal of flexible, small, readable, plain text files that is the problem. That the underlying init system of linux no longer follows the linux philosophy boggles the mind.

ayrx 11 years ago | |

You don't like systemd but it's probably time to accept the fact that it has "won". Most major distros including Debian is switching to it so it will get harder and harder to avoid. Might as well make the effort to learn it now.

ck2 11 years ago | | |

Technically I don't have to accept it until 2020 ;-)

(and FreeBSD has declared they will never use it, which to be fair is easy for them to declare since they cannot use it because it requires posix) (correction: not posix, cgroups and udev)

rwmj 11 years ago | |

You can enable text log files by installing 'rsyslog'. You only have to install the package, no further configuration is needed.

ck2 11 years ago | | |

Would the server then do two writes, both to the binary log for systemd and then to rsyslog?

I suspect so, because systemd needs it's logs for internal analysis?

mhurron 11 years ago | | |

And you should probably make sure that you do since every existing log analysis tool requires text logs.

Also, remote syslog, which journald doesn't support.

currysausage 11 years ago | |

> No more easy editing/understanding grub.conf

Oh, that's beautiful. And if you want to get s..t done, you can't even quickly search the manpage, because for religious reasons, GNU projects use that weird (and traditionally utterly verbose) info system. But hey, GNU is for GNU's Not Unix, so we shouldn't be too surprised ...

It's not like I didn't appreciate what the GNU project has done for the free software world, but it's so annoying that they seem to be focused more on religious matters than on writing good (well-documented, easy-to-configure, non-bloated) software.

I'm doing more and more server stuff with the BSDs, simply because the docs are so well-written and if I want to understand some part of the system, it doesn't feel like there are numerous layers of abstractions hiding away the interesting parts from me.

vomitcuddle 11 years ago | |

XFS and its lack of data journaling (it only journals its own metadata) is notorious for corrupting data on power loss and kernel crashes. It performs well only under specific workloads and hardware setups.

Why choose it as the default filesystem in an enterprise-oriented distro?

jacquesm 11 years ago | |

XFS is a dealbreaker for me. Nothing but bad experiences with that particular FS, especially when the filecount goes up.

ck2 11 years ago | | |

Note that of course you can still choose to use EXT4 when installing 7

SEJeff 11 years ago | | |

So use ext4, it isn't as though ext4 isn't included :)

pling 11 years ago | |

Thanks for posting this. That's what i was expecting.

Does any of that really improve my day?

Nope. In fact most of it makes it worse and adds friction. More cogs turning in different directions.

Will keep our devops stuff on CentOS 6.5 for at least another 4 years...

nodata 11 years ago | | |

Will keep our devops stuff on CentOS 6.5 for at least another 4 years...

What if someone needs one of the newer packages provided by RHEL7?

ch_123 11 years ago | |

> systemd replaces init.d

CentOS 6 had Upstart, right? Which is likely to become deprecated due to the fact that Ubuntu is also moving to systemd.

Sure, Red Hat are the ones pushing systemd, but some disruptive change away from Upstart was inevitable.

alokyadav15 11 years ago | |

I think its a RC of CentOS 7 because of "POTENTIAL" word .

bearlikelion 11 years ago | |

As excited as I am for 7.0 I highly dislike the systemd and grub changes. I'll wait for benchmarks before I decide to go to 7.0 or fully switch my stack to Debian

octo_t 11 years ago | | |

debian is also switching to systemd

nodata 11 years ago |

Site seems down, but an aggregator has a mirror (see the second entry): http://planet.centos.org/

----

copy/paste if that goes down too:

hi,

At this point we have a set of images that we consider release grade, pending final testing, we will move to release these unless a major blocker is reported.

folks with bandwidth to spare are encouraged to help seed these images via torrents, here are the urls to hit:

http://mirror.centos.org/centos/7/isos/x86_64/CentOS-7.0-140...

- KB

AlexMax 11 years ago | |

It's quite sad, in my opinion, that this is halfway down the page while yet another beating of the dead horse that is the systemd flam^H^H^H^H discussion is the most visible comment thread. Thank you for posting this.

peterwwillis 11 years ago |

If I were a large enterprise I'd reconsider CentOS. RedHat's lack of a commitment to the customer's experience in favor of RH's personal design preferences smacks of Oracle-ism. Anything they develop they immediately force on their users, and you have to just accept it rather than use it optionally. It's less easy to get away from those kind of changes versus something more open like ubuntu/debian (and I have no love for debian). And then there's the whole secret kernel patches and backported "features"... Then again i'm a dirty hippie who prefers Slackware, so maybe i'm too Linux-libertarian for today's enterprises.

facorreia 11 years ago |

Looks like a release candidate.

> At this point we have a set of images that we consider release grade, pending final testing, we will move to release these unless a major blocker is reported.

leog7 11 years ago | |

the site is not loading what's new besides upgrades?

facorreia 11 years ago | | |

That page was just a list of links to download the images for testing.

netcraft 11 years ago |

looking forward to trying systemd, hope it isn't too much of a learning curve.

Looking at: http://tecadmin.net/red-hat-enterprise-linux-7/# - will HAProxy come with centos 7?

msumpter 11 years ago | |

Anything that is in the standard release of RHEL7 will be in CentOS7. But for sanity sake I checked one of the 7 mirrors and there is an HAproxy (1.5) RPM: http://mirrors.easynews.com/linux/centos/7/os/x86_64/Package...

SEJeff 11 years ago | |

It honestly isn't. The documentation is really good if you know how to use google.

pling 11 years ago | | |

Until its your network gatewayb appliance that is down and then you're fucked...

NEVER rely on Google for documentation or GNU info as that's probably not installed on your server.

This sort of scenario is where *BSD win every time.

Mojah 11 years ago |

A few mirrors already have the full version, so if the site is offline, you can - for instance - grab one from a Belgian hoster; http://centos.mirror.nucleus.be/7/

atoponce 11 years ago |

I guess the server is getting slammed, as I cannot get to the main page.

infocollector 11 years ago |

Where is the ARM version? Anyone knows?

lpinca 11 years ago |

Title updated.

- simple "init script" like upstart, so magical or crappy shell scripts from vendors are a thing of the past. A standardized unit file - Ulimit support natively as part of the format - Limiting via memory/disk/cpu cgroups to contain buggy apps (hello mysql!) - Process restarting so tools like supervisord, monit, runit, etc are no longer necessary - It can _always_ stop an errant daemon as it uses control groups to do so, sysv init was sometimes buggy in this regard - Private /tmp (via filesystem namespaces), limiting system calls a service can run, tcp wrappers, read only parts of the filesystem (like /etc) are all trivial to add to any legacy service such as bind or sendmail and a supported part of the systemd unit file definition.