Forgot your password?
typodupeerror
Red Hat Software Open Source Linux

Red Hat Enterprise Linux 7 Released 231

Posted by Soulskill
from the onward-and-upward dept.
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.
This discussion has been archived. No new comments can be posted.

Red Hat Enterprise Linux 7 Released

Comments Filter:
  • Source RPMs (Score:5, Informative)

    by kthreadd (1558445) on Tuesday June 10, 2014 @02:54PM (#47205257)

    I was going to the FTP site to look at the sources [redhat.com], 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... [centos.org]

    That's a bit cool actually.

  • by psergiu (67614) on Tuesday June 10, 2014 @02:54PM (#47205261)

    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/ [boycottsystemd.org]

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      But a lot of them will. It turns out that systemd is actually kind of good.

      • For a large chunk of users, no diffence.

        For people who dig deep in, huge difference with very polarizing attributes. Some people like the goodies it brings, but it changes a whole lot of stuff in the process without much of a care for appeasing those that appreciate how things worked.

        Basically, systemd is building something different. Some say better, some say worse. I happen to be in the latter camp even after using it at significant length.

        • by arth1 (260657)

          For a large chunk of users, no diffence.

          Thing is, though, Red Hat Enterprise Linux isn't run by users, it's run by sysadmins, for whom it makes a huge difference. And not for the better.
          A system with hundreds of Windows .INI files and three layers of abstraction isn't particularly sysadmin friendly..

    • by Peter H.S. (38077) on Tuesday June 10, 2014 @03:46PM (#47205773) Homepage

      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/ [boycottsystemd.org]

      Systemd is the new future toolbox for maintaining and running Linux: All major enterprise Linux distros are using or are about to use systemd. Sure, a few companies will delay their transition to systemd if they have a lot of custom stuff they need to change, but systemd just have so many new awesome features that most will embrace it with joy; systemd simply means faster and better maintenance, and being able to pack more services in each hardware unit.

      Those who dislike systemd are just a tiny but vocal minority; they have also spend the last couple of years smearing named open source developers like Lennart Poettering and trash-talking systemd, instead of developing an alternative to systemd. As a group they accept how the most extreme voices against systemd are unopposed, meaning that all the swivel eyed loonies with their paranoid ranting have become spokespersons for them, resulting in that nobody wants to work with them. So not only are the systemd detractors a small group, but they alienate most of the potential developers they could have had.

      The end result is that almost nobody works on alternatives to systemd. Critical software like "ConsoleKit" is bit-rotting, nobody tries to help upstream projects supporting anything else but logind, despite that eg. Gnome developers have warned about this for years.

      Instead of helping KDE and Gnome supporting non-systemd systems, the systemd detractors just rant on how NSA/The Greys/Poettering are controlling Gnome and KDE, and that everybody should boycot them and use CDE instead.

      Like it or not, systemd will be in any Linux distro of importance in the future. Sysvinit (and X) are on life support and will be killed off at first opportunity people get. Even OpenBSD are starting to clone certain parts of systemd, and there is no doubt that all BSD's will have their init-system upgraded to a modern version inspired/cloned from systemd in the upcoming years. It is simply that good.

      • by armanox (826486)

        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/ [boycottsystemd.org]

        Systemd is the new future toolbox for maintaining and running Linux: All major enterprise Linux distros are using or are about to use systemd. Sure, a few companies will delay their transition to systemd if they have a lot of custom stuff they need to change, but systemd just have so many new awesome features that most will embrace it with joy; systemd simply means faster and better maintenance, and being able to pack more services in each hardware unit.

        Those who dislike systemd are just a tiny but vocal minority; they have also spend the last couple of years smearing named open source developers like Lennart Poettering and trash-talking systemd, instead of developing an alternative to systemd. As a group they accept how the most extreme voices against systemd are unopposed, meaning that all the swivel eyed loonies with their paranoid ranting have become spokespersons for them, resulting in that nobody wants to work with them. So not only are the systemd detractors a small group, but they alienate most of the potential developers they could have had.

        The end result is that almost nobody works on alternatives to systemd. Critical software like "ConsoleKit" is bit-rotting, nobody tries to help upstream projects supporting anything else but logind, despite that eg. Gnome developers have warned about this for years.

        Instead of helping KDE and Gnome supporting non-systemd systems, the systemd detractors just rant on how NSA/The Greys/Poettering are controlling Gnome and KDE, and that everybody should boycot them and use CDE instead.

        Like it or not, systemd will be in any Linux distro of importance in the future. Sysvinit (and X) are on life support and will be killed off at first opportunity people get. Even OpenBSD are starting to clone certain parts of systemd, and there is no doubt that all BSD's will have their init-system upgraded to a modern version inspired/cloned from systemd in the upcoming years. It is simply that good.

        Systemd is not "that good." As an opponent myself, I am an admin, not a developer. And as an admin, I fail to see what was wrong with the BSD Init system. It works. It's simple. It's good.

        And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.

        • by Peter H.S. (38077)

          Systemd is not "that good." As an opponent myself, I am an admin, not a developer. And as an admin, I fail to see what was wrong with the BSD Init system. It works. It's simple. It's good.

          And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.

          There are many not so nice things about old style init scripts. Come on, executable config files where code and declarative statements are mixed? Who thought that was a good idea? Many people also find that debugging such scripts are hard etc. But the main thing isn't so much that old style script init systems are inherently bad, but that they don't work well with modern day computing.

          The days of running a handful of services on a single server, directly on the metal, while hand crafting scripts, are basica

        • by arth1 (260657)

          And as far as Mr. Poettering goes, I much prefer to trash talk his work. Attacking him, no matter what you may think of him, doesn't get the point across.

          Attacking Lennart Poettering is a bit like pouring water on a duck. I think the ability to consider the opinions and experience of others is completely missing. Input is only accepted if it's praise or furthering the direction he's already staked out (and even then he's thrown ego tantrums).

          The point that gets across to Red Hat is our money. Money that

          • by Peter H.S. (38077)

            Attacking Lennart Poettering is a bit like pouring water on a duck. I think the ability to consider the opinions and experience of others is completely missing. Input is only accepted if it's praise or furthering the direction he's already staked out (and even then he's thrown ego tantrums).

            Around 500 different developers have contributed to the systemd project. It just shows that the project have excellent leadership with Lennart Poettering since he can attract so many developers across so many differen

      • by Junta (36770)

        instead of developing an alternative to systemd

        The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.

        Instead of helping KDE and Gnome supporting non-systemd systems,

        KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any

        • by Peter H.S. (38077) on Tuesday June 10, 2014 @04:53PM (#47206343) Homepage

          instead of developing an alternative to systemd

          The stance amongst those opposed to systemd was that what wasn't broken didn't need fixing. Some people disagree and think it needs to be fixed and systemd is it. People objecting to systemd largely don't have to create an alternative, they are content with the linux distributions as they were.

          Of course you need to develop alternatives to systemd in order to decay into non-functionality. AFAIK, running a multi-user non-systemd OS these days, depends on a old bit-rotting version of ConsoleKit. There are many more features that will break and bit rot in the future for lack of maintenance; Red Hat, Suse, Debian, Ubuntu, etc. won't put resources into developing for non-systemd systems.

          Instead of helping KDE and Gnome supporting non-systemd systems,

          KDE at least I thought purported to continue supporting non-systemd systems already. Gnome 3 developers very linked in with the systemd developers and as a whole they prioritize the purity of their vision over any criticisms. Perhaps appropriately electing to focus on bringing their vision to life to serve those who would follow the vision and letting the rest go on to KDE or xfce or MATE or whatever. I personally don't care about gnome shell as it doesn't serve my needs anymore either, but I can accept that they are caring after their user experience. I also wouldn't mind systemd so much except for the fact it is becoming unavoidable whilst retaining compatilibity with ongoing projects in linux.

          KDE will support running on non-systemd distros, but it will be with reduced functionality. Not because the KDE developers are evil, but because they are offered no alternatives to systemd. Take fx. the new KDE login manager; KDE simply couldn't afford spending developers so that it also supported the rather broken and bit-rotting ConsoleKit. And nobody else has stepped up and offered help.

          Sure you can use another login manager, but it is just an example on how bit by bit, non-systemd distro will have to step up and start doing their own development in order to have functional software. Networking and ntp DE modules, and log viewers, etc. will all be systemd based, with no common alternative in sight.

          Gnome developers have warned for years about current problems; systemd offers really good and compelling features that can enhance their DE, while non-systemd distros doesn't. And because non-systemd distros seems to be sticking their head in ground and denying the reality that status quo can't be maintained, they don't offer any help at all. In fact, snarky remarks and vague conspiracy insults are all they are getting.

          • by fnj (64210)

            Sure you can use another login manager

            My "login manager" is init calling getty which calls login which gets me to bash. If I want pretty pictures, from there I just run startx, which gets me into KDE or whatever else is configured. AFAICT, KDE doesn't care how it gets started. My way seems the most straightforward to me. How is it sticking my head in the ground?

    • by Tailhook (98486)

      I bet they'll have to support RHEL6 for many and many years

      Red Hat is committed to supporting RHEL6 until Nov. 2020, and Nov. 2023 with extended support, nearly 9 more years,. What, exactly, is your point?

      Long term support is one of the appeals of Red Hat..... they get paid for it.

  • by B5_geek (638928) on Tuesday June 10, 2014 @02:55PM (#47205269)

    I have always admired RH for it's feature set and pursuit of enterprise-related features.
    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? /etc/network/interfaces
    vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

    • by thaylin (555395)
      Because some people like /etc/network/interfaces and some people like /etc/sysconfig/network-scripts/. When you can fork the software people tend to start putting things where they want. You prefer the first, I the latter, as I have been working on systems with it for 14 years.
      • by jandrese (485)
        I prefer /etc/rc.conf personally. I'm not sure why every interface needs its own config file.
        • by kthreadd (1558445)

          It's much easier to handle large scale automation when you're using separate files.

          • by arth1 (260657)

            It's much easier to handle large scale automation when you're using separate files.

            And much harder to admin heterogenous networks where different services are normally run on each system, but you want them installed in case you need to take over a service during maintenance or otherwise.

            • That's what RH Clustering Services are for...

              • by arth1 (260657)

                That's what RH Clustering Services are for...

                I said "heterogenous", not "homogenous".
                Not HA for failover when something goes wrong, but manual changes to services on different boxes with different primary functions.

        • by B5_geek (638928)

          Since I have have started seriously working on BSD systems I have enjoyed the simplicity/straight-forwardness of it's configuration setup. The only thing that keeps me from switching to OpenBSD for all my servers: apt-get dist-upgrade

          I have only been bitten in the ass once by this (15'ish years ago), and it makes keeping the system updated so easy.

          • by fnj (64210)

            All of them are fucked up when it comes to network interfaces - linux, BSD, Windows, OSX, you name it. Why should a network interface device be some kind of black magic rather than a node in /dev like every single other device? I never understood the point of this.

            At least in BSD it's pretty straightforward to figure out what the fucking NAME of the goddam ethernet device is.

          • by fnj (64210)

            The only thing that keeps me from switching to OpenBSD for all my servers: apt-get dist-upgrade

            If you had gone FreeBSD rather than OpenBSD, you would have freebsd-update and pkg. It's not QUITE as straightforward as "apt-get dist-upgrade", but pretty damn close.

            To update base OS, "freebsd-update fetch && freebsd-update install". With the right syntax, you can even upgrade your base OS across minor and major releases. Don't worry, that only happens if you deliberately call for it.

            To update userland p

    • by Peter H.S. (38077) on Tuesday June 10, 2014 @03:20PM (#47205521) Homepage

      I have always admired RH for it's feature set and pursuit of enterprise-related features.
      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? /etc/network/interfaces
      vs /etc/sysconfig/network/networking/where/are/the/damn/config/files

      I think the differences are just the normal fragmentation between different distros, with everyone having their own idea of the "correct" place to put the config files. The systemd project is trying to establish a cross distro standard for some of the important config files, making it easier for upstream projects to know where e.g. /etc/os-release is (on non-systemd distros it can be "hidden" almost everywhere).

      Systemd is the most important new feature of RHEL 7, since the core of the OS now have been making a huge leap forward in security and reliability regarding processes and deamons. It is now a piece of cake to utilize advanced kernel features like "capabilities" http://man7.org/linux/man-page... [man7.org] and "cgroup" https://www.kernel.org/doc/Doc... [kernel.org]

      All major distros are about to change to "systemd"; Red Hat, Suse, Ubuntu, Debian. Their derivatives like CentOS, Sci-Linux, Fedora etc. are also changing to systemd, so in a few years, systemd will simply be the new standard toolbox to maintain and run Linux distros, and part of the new future Linux development stack; systemd, Wayland, cgroups and kdbus.

      So every Linux System Administrator who have been to procrastinating regarding learning systemd, better start reading up on the subject. A good place to start is : http://www.freedesktop.org/wik... [freedesktop.org]

      • by thaylin (555395)
        How much did Lennart pay you? 8)
        • by Peter H.S. (38077)

          How much did Lennart pay you? 8)

          Hey, lets look at your sig:

          --
          When you cant win, ad hominem.

          Had you forgotten all about your own sig?

          This is exactly why systemd detractors have lost every technical argument and lost out on all major Linux distros; you are wasting time on negative campaigning against systemd instead of getting off your asses and start coding alternatives.

          You have lost wholesale to systemd because you wasted time smearing open source developers like Poettering behind your anonymous handles instead of working.

          • by fnj (64210)

            As one who has taken strong exception to both the form and substance of the systemd steamroller, I readily volunteer that Peter has a point. If you don't think any alternative to some form of init scripts is necessary, just say that. Peter and other proponents will make a strong well-supported point-by-point case for the alternative-IS-required viewpoint.

            Peter - hi - I still dig BSD with init scripts, particularly FreeBSD, but I'm not manning the barricades against linux with systemd. I do run arch with sys

      • Will registryd be part of systemd soon? I can't wait having some centralized binary configuration only readable by systemd utilities.

        • by fnj (64210)

          Well, journald is sort of the mirror of the hypothetical registryd, and journald is quite well established and doing fine at this point. The comparison is far from perfect; for example you can still run syslog in parallel with journald, but on the mirror side you pretty much would need to pick one-and-only source of config data.

          A case can certainly be made for a registryd. It is appealing to have all your config info nicely hierarchically arranged in a single tree, rather than hunting for scattered files am

  • Their use of bold and italics in the announcement makes me feel like I'm reading an old John C Dvorak pcmag column.

  • XFS and PCP are good things to include.

    systemd and OpenLMI I find worrisome. systemd being the one impossible to ignore so OpenLMI at least gets something of a pass for the ability to totally ignore it.

    systemd has been hashed out time and time again, but OpenLMI is something rarely discussed. DMTF has championed CIM for eons, and the architecture shows in that it clearly defines things as you would see a buzzword compliant enterprise define an architecture amidst the dotcom boom of the late 90s (complete

    • systemd is nice since it can keep your services running, alert you to problems, and tell you why they failed when there's no logs coming out.
      • Re:Good and bad... (Score:5, Insightful)

        by thaylin (555395) on Tuesday June 10, 2014 @03:14PM (#47205451)
        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.
        • by iggymanz (596061)

          funny I can do a parallel start up with init script if I really wanted to, don't need fancy bloated startup/system/session manager

          • by thaylin (555395)
            hey I am with you, just saying the bloatware that is systemd is not needed, and in my case not wanted.
        • by Peter H.S. (38077)

          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.

          This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities", sand-boxing deamons so that privilege escalation is impossible, or forking etc. It also makes it a breeze to use cgroup, making it easy to control system resources to keep the system up and stable in case of DoS'ing, it has rate limiting, and a total supervising chain of all processes and deamons, including itself, etc. etc.

          It is also very modular. For some reason systemd-detractors keep on saying that syste

        • by amorsen (7485)

          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 e

          • by arth1 (260657)

            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.

            One reason why stuff got moved out of inittab was precisely to avoid apps being restarted if they died. The admins needed to find out why a process was dead.
            Also the ability to stop and start processes without modifying inittab and doing "telinit q".

            And now we're back to modifying files again, in a monolithic system with more arms than an octopus, sucking everything in. No, thanks. The Unix toolbox approach is that apps should be small, do as few things as possible, and do them well. Give the admins mor

    • by thule (9041)

      Microsoft de-emphasized CIM? DSC (Desired State Configuration) is entirely based on CIM. It works by creating CIM objects with Powershell. It will create a corresponding .mof file from the provider written in Powershell. Once you have the mof and the provider, the provider can be called from Powershell. DSC will manage the state of the provider based on the parameters passed by the configuration script.

      MIcrosofties where I work are all excited about DSC. I think they think is Chef/Puppet for Windows. I don'

      • I will say I didn't mess with DSC, but a lot of the .NET calls no longer rely upon WMI working. WMI like sfcbd and Pegasus will completely cock up if a provider so much as looks at it funny. Previously, only utilities like ipconfig and stuff would keep working and any thing making WMI calls was just SOL. I noticed in one of the various scenarios where WMI had gone belly up that the calls I had moved to in .NET didn't mind at all for a lot of the stuff. Someone at MS suggested that WMI/CIM was being step

        • by thule (9041)

          Very, very interesting. I don't work in the Windows world, but I will pass along this information about WMI on Windows to the people testing DSC. If WMI isn't right all the time, then DSC is not going to work.

          What .NET calls used to require WMI?

  • by iggymanz (596061) on Tuesday June 10, 2014 @03:21PM (#47205527)

    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!)

    • It's not what it's capable of, it's what's been tested and is supported. You can certainly go bigger if you want, but don't expect support.
      • by iggymanz (596061)

        funny, a couple of their competitors have no such limitations. That is like Cisco charging you for switch port use

  • by nimbius (983462) on Tuesday June 10, 2014 @03:24PM (#47205559) Homepage
    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!
  • I really don't like the fast release cycle of many Linux distros, so I used to stick with CentOS or RHEL on my desktops as well. What about RHEL 7? By the way, what filesystem should be used on a laptop?

    • by kthreadd (1558445)

      I really don't like the fast release cycle of many Linux distros, so I used to stick with CentOS or RHEL on my desktops as well.

      It's Gnome 3.8, which is a good desktop in my opinion. But you take some time should try it out yourself.

      What about RHEL 7? By the way, what filesystem should be used on a laptop?

      Any file system should be fine. Go with the default if you're not sure you want something else.

      • Re: (Score:3, Interesting)

        by armanox (826486)

        Use ext4 for a laptop over the default, XFS. XFS is prone to data corruption when improperly shut down.

        • by kthreadd (1558445)

          That's true, although I would suggest that you also don't improperly shut down your laptop. :-)

        • by Eric Smith (4379)

          XFS is prone to data corruption when improperly shut down.

          Really? Ugh. I thought most modern file systems were consciously designed to avoid that sort of problem.

          • by armanox (826486)

            I'd hardly consider XFS modern. SGI introduced it on IRIX 5 back in the mid 90's.

        • by arth1 (260657)

          Use ext4 for a laptop over the default, XFS. XFS is prone to data corruption when improperly shut down.

          No, it isn't. It is prone to data erasure, which is different. XFS log playback will, by default, zero any data that cannot be played back in full, because it may be data that should not be exposed. It's a feature that makes XFS largely immune to some power-yank attacks that other systems are vulnerable to.
          You want to use barriers, and if possible, keep at least your log areas on battery backed storage.

  • Reverting to init (Score:3, Insightful)

    by hankypooh (1175467) on Tuesday June 10, 2014 @04:47PM (#47206279)
    Can one revert to init, rather than using systemd?
    • by kthreadd (1558445)

      What do you mean by init? There's still a binary called init if that's what you want. And RHEL 6 used Upstart, but I don't know if that's more init than Systemd. So yes in theory you can since you have access to the source code and can modify it any way you want. This will be cumbersome in practice.

Always draw your curves, then plot your reading.

Working...