Slashdot Mirror
Red Hat Enterprise Linux 7 Released
An anonymous reader writes: Today, Red Hat unveiled Red Hat Enterprise Linux 7, with new features designed to meet both modern datacenter and next-generation IT requirements for cloud, Linux Containers, and big data. The new version includes Linux containers (LXC), which let Linux users easily create and manage system or application containers, improved MS Active Directory / Identity Management (IdM) integration, XFS as the default file system, scaling to 500 TB (additional file system choices such as btrfs, ext{3,4} and others are available), a new and improved installation experience, managing Linux servers with OpenLMI, enhancements to both NFS and GFS2, optimized network management, bandwidth, the use of KVM Virtualization technology and more. See the complete list of features here (PDF). CentOS 7 shouldn't be lagging too far behind due to recent cooperation between Red Hat and CentOS project.
Stable is the word you are looking for.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
rhel7 comes with glibc 2.17.
There are scenarios in which a meticulously backported base with few to no functional changes is valuable. That is the entire point of RHEL, to be able to have support lifecycle that more closely matches Microsoft or Unix offerings.
If you need more rapidly updating content, then a distribution like Ubuntu or Arch or Fedora is a better fit. Ubuntu LTS might be a decent approach for some. The good thing about this ecosystem is you can select an experience based on your needs.
XML is like violence. If it doesn't solve the problem, use more.
I was going to the FTP site to look at the sources, but apparently they have moved.
Current sources for Red Hat Enterprise Linux 7 have been moved to the following location:
https://git.centos.org/project...
That's a bit cool actually.
I bet they'll have to support RHEL6 for many and many years as a lot of companies won't upgrade to RHEL7.
http://boycottsystemd.org/
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
I have always admired RH for it's feature set and pursuit of enterprise-related features. /etc/network/interfaces /etc/sysconfig/network/networking/where/are/the/damn/config/files
I do however have one gripe: All the config files are in the wrong place!
This isn't a real complaint, more akin to a whine. I have been using Debian for too many years on far too many servers; my muscle memory demands that the config files that I need to edit be located in the same place across distros.
Does anybody know why there is such a difference in file locations?
vs
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
Yep, but the problem is that for the next ten years it will _still_ come with glibc 2.17. Some people actually new new apps too.
This is where containers is a good idea. Use RHEL as a stable base system and run something like Fedora in a container for the few apps that need it.
Red Hat aims not only for stability in the sense of "not crashing", but in the sense of "doesn't change a lot within a major release", especially in the core libraries and language runtimes. Companies often like that kind of stability, because they have miscellaneous in-house or commercial software running on top of the base system, which has a habit of breaking when anything is upgraded under it. So within a major version, Red Hat carefully rolls out only non-ABI-breaking changes, e.g. by backporting bugfixes to previous major versions of libraries.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Systemd is not nice because it does all that stuff. Init is not supposed to do all that stuff, because it makes it bulky, gives additional avenues of attack, and is just all around a pain. What would have been better would have been to make systemd a modular system so that if you want it to handle all that, it can, but if you dont, it just does the parallel start up.
When you cant win, ad hominem.
XFS on 64 bit linux can go to 8 EB for files and volumes, a tad bigger than 500TB. Did Red Hat cripple it (for a while they even charged extra for XFS!)
C-Level: Red Hat has a new version of internet, we should install it.
PHB:right away! PM! Red hat has an OS! lets install it
PM: Of course! Engineering! how are we on the RHEL 7 project!?
Senior Engineer: I dont remember getting one did I give it to you?
Infrastructure group: you never approved our upgrade to RHEL 4 because it required Oracle downtime. You never agreed to the RHEL 3 upgrade because our proxy cant go down or the PHB cant get to facebook. We were told not to upgrade the RHEL 2 fileservers because the PHB keeps his motivational MP3's there. The only machine we have running RHEL6 is the one you made us install four days ago because you attended a webinar..so...i guess we'll have it upgraded by the end of the week.
PHB: whoa there pump your brakes guys...dont touch that server. if you take it offline i might not be able to get to the webinar next year!
Good people go to bed earlier.
I guess I didn't explain that very well.
Libvirt provides its own container launcher under the name "lxc". As I understand it this software is developped and maintained with libvirt. This is different software from the standalone project known as "LXC" as linked in the article.
BULL SHIT.
Redhat routinely changes shit horrendously within release. They removed the crmsh configuration and replaced it with a completely different configuration tool in RHEL6, breaking a bunch of shit. They do this continuously: upgrade software, change some shit around, deprecate old tools for new tools, and tell you it's improved.
crmsh was in tech preview. Red Hat never committed to supporting that. Pay attention to the support status of what you are deploying.
RHEL is about as change averse as a *Linux* company gets. They have the unfortunate balance to play between fulfilling the mission of a solid predictable experience and not appearing to lag so much compared to the base people are well aware of. At times, I will say RHEL is in denial about ABI-breaking changes (e.g. swearing up and down that a kernel driver should compile and work against their rather dramatically backported base just as if it was really the kernel version advertised in uname output).
If you want 'stuff that never changes while still giving new hardware support', you are pretty much stuck with AIX or mainframe at this point.
XML is like violence. If it doesn't solve the problem, use more.
Comparing apples to oranges when it comes to linux distros. RHEL is for mission critical stability and especially servers where you don't want stuff changing all the time. Rolling release distros are dangerous in production environments. Especially a distro like Arch takes way too much effort to setup and maintain. Not every computer is a hobby.
You think a hobby distribution that didn't even have package signing until 6 months ago is a competitor to RedHat?
It is 3.10. But keep in mind that this is only where Red Hat essentially forked their version. Each minor release adds major changes to the kernel, including both hardware support and new features.
init IS supposed to know whether services are running and restart them if they fail or exit. It used to do that way back when; you would edit /etc/inittab to specify what runs at which runlevel. Unfortunately /etc/inittab was sufficiently crap that all sorts of things were pushed into shell scripts instead, which lost the the ability to recover from failed services. Then you could install Monit and edit those shell scripts to get that ability back, but every time you upgrade you have to check whether your edits survived. Not nice.
A replacement for init was sorely needed.
Finally! A year of moderation! Ready for 2019?
You are missing the whole point - the idea is that throughout the 7.x release the glibc (/ other software) version will not change, so in 10 years time your *current* software investment will still work, rather than being force to upgrade. Stability means not changing what is deployed *now* in the future. For many deployments this is crucial. If you do not need this form of long-term software stack stability, then, yes, RedHat is not for you - however there is no point criticising RedHat for a policy that is deliberately enforced for a good reason.
Use ext4 for a laptop over the default, XFS. XFS is prone to data corruption when improperly shut down.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
I agree that long-term ABI stability is important. But on AIX, they've managed to maintain backward compatibility for years. Almost everything built on way old versions of AIX runs on the latest version. If they have to provide multiple versions of some libraries to handle broken old behaviors, they do that too. Maybe I'm missing something here - like maybe AIX includes a much smaller set of libraries than RedHat. But for the purposes of our apps, AIX has been a really nice, stable platform. Nothing flashy, but no surprises.
Posted from my Android phone. Oh, I can change this? There, that's better...
Can one revert to init, rather than using systemd?
Scientific Linux will probably still beat CentOS to the punch. They did with 6.
Initially, yes. CentOS narrowed and then beat SL with each point release
Now that CentOS is part of RedHat, I would expect that CentOS should be able to keep pace.
Pacemaker (which provides crmsh) is a tech preview and unsupported in rhel. But don't let that stop you from blaming them for something that you know, is unsupported...
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Like SELinux, I'm afraid that it's complex, incomprehensible and unusable to the average developer, and is immediately thrown away or never even usable to most developers. ...
You are absolutely right, that advanced kernel features like "capabilities" and "cgroup" are hard to use for developers. That is the exact reason for why "systemd" was made as a "Linux plumbing layer" that makes advanced and powerful new kernel features easy to use for everybody.
With systemd, it is a one liner in a text config file to turn on really powerful service sand-boxing features like preventing the service, even if exploited, to gain new privileges.
Or use the "ReadOnlySystem=" to make "/boot" and "/usr" read-only for the service; even if the service is exploited to run code with root-privileges, the /boot and /usr directories will be read-only for that root executable (and all other instances/processes that stems from that).
This is great stuff; even the distro maintainers can turn on powerful "Kernel capabilities" as default. There is no need to patch code, or ask the service developers to understand anything about it, or develop against it.
Same with "cgroup". It is a one-liner to enable powerful system usage limits, or giving a certain service net/cpu/IO priority.
"Capabilities" are meant to be used together with a MAC like SElinux, and normal ACL's, but thanks to systemd, it is extremely easy to use. No need for compiling custom kernels, hand crafting scripts that are distro specific, or similar barriers; just adding simple keywords to a text config file, and systemd will take care of all the behind the scene magic.
Seriously....makes me want to scream (or did, I left that place), and you really think having the latest wiz-bang tools available is anything but the least of my worries? Not in production it isn't.
Yup, having been in a production environment with 1000's of machines, you get very 'risk averse' - your job is 24/7/365 uptime, making sure nothing breaks, *NOT* having the latest whiz-bang tools to play with.
Thus speaks someone who has never seen a crash/restart loop. Large apps like databases can take several minutes to start up and recover, and then immediately die again. The next morning you have several terabytes of core dumps, and a corrupt database, and have to restore the latest backup.
That situation is easily handled by systemd since it has total knowledge and supervision of all running processes and services, and has extensive capabilities for various ways of restarting crashed services. This included ways to limit restarts, so as if a services crashes more than eg. two times within eg. 10 minutes it wont restart that service again (or reboot the entire system, or many other actions). This is controlled by simple keywords added to the config files like "StartLimitInterval=, StartLimitBurst="
You can even make systemd clean up core dumps after a failure if that is what you want.
Here is a overview of the many fine grained service control mechanisms that systemd supports;
http://www.freedesktop.org/sof...