9 ms·

Red Hat Enterprise Linux 7.4 Released

80 points by gtirloni 9y ago

Mojah 9y ago
A very big change, although not widely reported, is the update to OpenSSL 1.0.2k, which brings ALPN to RHEL & CentOS. This in turn allows HTTP/2 on Chrome to work again if you're using Nginx as a TLS proxy on your server. Some more info here; https://ma.ttias.be/rhel-centos-7-4-restores-http2-functionality-nginx/ https://ma.ttias.be/rhel-centos-7-4-restores-http2-functiona...
- deleted 9y ago
  [deleted]
- lima 9y ago
  Another big change is SELinux support for overlayfs, which means you can use the overlayfs2 driver with Docker without disabling SELinux.
lima 9y ago
Really happy with my move from Ubuntu LTS to CentOS 7. QA is so much better. I had so many production breaking bugs with Ubuntu, especially on bare-metal. RPM packaging is more fun than DEB. I'm even using it for application deployment with tito[1]. Even the software deployment story got better thanks to the Software Collections (https://www.softwarecollections.org https://www.softwarecollections.org). Rock solid base OS and an up-to-data application stack. CentOS on the servers + Fedora desktop is a great combination, since you can re-use your whole build infrastructure and skills for your workstations. [1]: https://github.com/dgoodwin/tito https://github.com/dgoodwin/tito
- gtirloni 9y ago
  Well, kind of up-to-date application stack. If you worry about security fixes, SL repositories don't usually have the latest versions. E.g. PHP7 repo still has 7.0.10 [0] Re: stability and QA, couldn't agree more. I only briefly used Ubuntu LTS in production back in '10 and it wasn't a fun experience. I'm sure it has improved but RHEL/CentOS (almost) never lets me down in that regard. 0 - https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-php-could-allow-for-arbitrary-code-execution/ https://www.cisecurity.org/advisory/multiple-vulnerabilities...
  - bubblethink 9y ago
    >Re: stability and QA, couldn't agree more. While generally all LTS distros are quite good these days, I've found that, unsurprisingly, features that are developed heavily or owned by a single distro end up being rocky. RHEL has a lot of things that are not as heavily used elsewhere, and they are far from production quality. For eg., their lvm thin provisioning feature, is pretty rough, and had some very obvious failure cases that could even lead to data loss. I'm guessing that no one uses thinp in production.
    - lima 9y ago
      Please elaborate. I do use thinp in production (OpenShift + devicemapper pool as Docker backend, which uses thinp).
      - bubblethink 9y ago
        The default metadata pool size chosen by anaconda, at least up to RHEL 7.3, is paltry. Something like 100 MB for terabytes of data. Why they chose that is beyond me. Anaconda won't let you configure it manually during installation either. It'll get full in no time. Automatic extension is disabled by default. If you're lucky, you'll realize this by looking at your own logs. Then you'll try to extend it, at which point you'll realize that extending it won't extend the pmspare vol, and you've effectively disabled the pmspare functionality.
        lima 9y ago
        Yes but that's well-known and documented. Including it in Anaconda looks like an oversight though (a thinp deployment needs to be well-planned and you'd definitely want to read the docs). There's a whole book-sized section about in the storage docs. The docker-storage-setup utility, for example, sets it up correctly and enables automatic extension.
        bubblethink 9y ago
        No, the use in Anaconda is perfectly legitimate. Docker aside, I use it for automatic snapshots. That's a fairly useful and unique feature that you can't have in any other legit way (not counting zfs, and btrfs is deprecated). There is also the yum-snapshot plugin that relies on it. It's not even that complicated. Just throw a few gigs at metadata and forget about extensions. If I have 2TB hard drives, I don't care if you use 16 G for metadata, which is the max.
- cjsuk 9y ago
  This. Our CentOS 6/7 deployment has been completely uneventful! Ubuntu going back to 10.04 LTS was hell.
- ashark 9y ago
  > QA is so much better. I had so many production breaking bugs with Ubuntu, especially on bare-metal. Is it (Fedora) much better on the desktop? I dumped Win10 a couple months ago to go back to Ubuntu for the first time since PulseAudio broke everything horribly and I swore off Linux on the Desktop forever (haha), and I was shocked to find that the UIs of both Gnome and KDE have if anything more rough edges than when I last saw them as far as usability goes, performance (UI responsiveness mainly) is generally mediocre to poor, and that both are at least as unstable/buggy as before (KDE significantly worse than Gnome in that regard, though neither's good). I'd consider jumping ship to an RPM-based distro for the first time since 2004 or so if the desktop experience is less... well, bad, frankly. Going back to Win10 isn't an option. What a garbage fire.
  - noir_lord 9y ago
    Xubuntu to Fedora XFCE spin was entirely unexciting in terms of change, I like unexciting when it comes to the OS I use for my livliehood. Gnome 3 is still a dumpster fire and KDE got so bad as packaged that the devs felt the need to do Neon. KDE hasn't been good imo since 3 and Gnome since 2. I'm an XFCE user because of the Gnome 2 debacle though I've considered MATE a few times there isn't anything about XFCE remotely bad enough to make me seriously consider a switch.
  - cjsuk 9y ago
    Gnome is just total garbage as is windows 10. They both drove me to OSX which I admit merely carries the crown of being "the least crap". I really want gnome2 back but fixed and as a first class citizen, not a fork that the big vendors wish would go away. That had some mileage.
    - davehtaylor 9y ago
      I love macOS. It's a Unix system, with a fantastic GUI, well-integrated applications, an ecosystem that is rich and vibrant, and a command-line system the is extremely usable, also with a rich ecosystem (homebrew, macports, etc) For me, after 10 years of trying to make desktop Linux work the way i wanted it to, macOS is everything I was looking for. Gnome decided that they had no desire to make a usable DE. They took everything that made it good, threw it out the window, and went as far as they could to make it unusable. KDE is just a clusterfuck. 2-3 system preferences panels, confusing options, and way too much gloss (glow, transparency, etc). I spent a long time with tiling window managers, trying to roll a system that felt comfortable and usable to me. And for the most part I succeeded. But the lack of integration with applications is really what ruined it for me. I want a good email client, an address book that can have arbitrary amounts of phone numbers and email addresses per entry, and the ability to give those arbitrary names. I also want my email, address book, and calendar to be aware of each other and play well together. I want a nice way to sync all of that to my mobile devices. I want an experience that feels coherent, instead of something hacked together with bailing twine. Don't get me wrong. I love Linux. For servers, I would never choose anything else (well, maybe FreeBSD). But it seems like over the last decade, distro developers and desktop environment developers have gone out of their way to sabotage their own efforts and make their software as unappealing as possible.
- dima55 9y ago
  I've had the opposite experience: compared to Debian, RPM distros feel like they were built by children. I guess YMMV :)
  - deleted 9y ago
    [deleted]
- dboreham 9y ago
  In my experience they wax and wane. We're on our fourth distro in 10 years. Change has mainly happened because "it don't work with the new hardware we just bought". Currently on Ubuntu fwiw.
- dozzie 9y ago
  > RPM packaging is more fun than DEB. How so? From my experience, these two are equivalent to a high degree and don't differ much, and I've built a lot of both.
- abrookewood 9y ago
  Interesting - I did the exact opposite. Red Hat have a habit of removing packages that compete with their commercial offerings, which forces you to either compile from source or to install from other repositories - for example, they removed Apache ActiveMQ because they offer JBoss AMQ. This starts to become annoying because all of a sudden you have multiple update processes to keep everything up-to-date, whereas previously, you had one. After being bitten by this at least twice, I shifted everything to Ubuntu.
rodgerd 9y ago
Notable point: Red Hat are effectively declaring btrfs has no future. From the release notes: "The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux." https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
- clem 9y ago
  I wonder if they'll be supporting ZFS on Linux now that it's gaining momentum?
  - ty_a 9y ago
    I highly doubt Red Hat will ever touch ZFS. Oracle and Red Hat have a very tenuous relationship. I hope Red Hat will support bcachefs though. I think it's the most promising alternative FS.
  - mattl 9y ago
    Unlikely, given the license of ZFS and its incompatibility with the GPL
- merb 9y ago
  didn't they settled to xfs long ago? Isn't the default root fs on fedora xfs?
  - bubblethink 9y ago
    Yes, btrfs was a tech-preview, meaning use if you want with no support or future guarantees. It has been officially dropped from future plans now.
    - lima 9y ago
      And they're working on adding CoW and deduplication to XFS.
flyinghamster 9y ago
One thing that is souring me on RHEL+clones is Red Hat's habit of yanking drivers for SAS and SCSI controller cards. On my home file server, CentOS 7 is the end of the line unless I buy a new HBA. Then there was the old Dell server at a customer's site that we were planning to use for a development/testing system. It had a perfectly functional PERC/4e RAID controller, but Red Hat yanked the driver in 7.0, never mind that Ubuntu Server works perfectly on the same hardware. We ended up picking up a cheap refurbished desktop to use as the development box.
- lima 9y ago
  Some examples would help. So far, any example of drivers disappearing that I encountered were due to quality issues.
  - flyinghamster 9y ago
    The abovementioned PERC/4e is an example. The driver was deprecated in RHEL6, and gone in RHEL 7. The card in my home server is an Intel SASUC8I reflashed with IT firmware, so it's equivalent to an LSI SAS1068E. The driver for that is listed as "deprecated" in 7.
    - wyoung2 9y ago
      Another is the 3ware 8000 series. We got a dead machine in recently for repair and were faced with either moving the RAID drives and card over to a new server chassis while being restricted to the EOL'd CentOS 5 or upgrading to CentOS 7 but being forced to buy a 9000 series card and rebuild the array. Lose-lose.
      - lima 9y ago
        Well, I can see why Red Hat wouldn't want to support those old cards forever. Including the driver would be easy, but actually supporting it (QA, support...) is not. They already supported them for close to 10 years, which is much longer than most hardware lifecycles last nowadays (3-5 years). You could still build a custom kernel but yeah.
smegel 9y ago
Nice.
toyg 9y ago
Does it come with python3 installed by default, like recent Fedora?
- Spiritus 9y ago
  No. And it won't be until (at least) RHEL 8. It's available from SCL[1] and IUS[2] though. [1] https://www.softwarecollections.org https://www.softwarecollections.org [2] https://ius.io https://ius.io
- carwyn 9y ago
  It's also in EPEL now. SCL is cumbersome by comparison for basic usage.
apearson 9y ago
Anyone know how much a lag CentOS is normally behind Red Hat releases?
- wyoung2 9y ago
  About a month: 7.0: 4 weeks 7.1: 3 weeks 7.2: 4 weeks 7.3: 5 weeks Source: https://en.m.wikipedia.org/wiki/CentOS#CentOS_releases https://en.m.wikipedia.org/wiki/CentOS#CentOS_releases

80 points by gtirloni 9y ago

A very big change, although not widely reported, is the update to OpenSSL 1.0.2k, which brings ALPN to RHEL & CentOS. This in turn allows HTTP/2 on Chrome to work again if you're using Nginx as a TLS proxy on your server. Some more info here; https://ma.ttias.be/rhel-centos-7-4-restores-http2-functionality-nginx/ https://ma.ttias.be/rhel-centos-7-4-restores-http2-functiona...

deleted 9y ago
[deleted]
lima 9y ago
Another big change is SELinux support for overlayfs, which means you can use the overlayfs2 driver with Docker without disabling SELinux.

lima 9y ago

Really happy with my move from Ubuntu LTS to CentOS 7. QA is so much better. I had so many production breaking bugs with Ubuntu, especially on bare-metal. RPM packaging is more fun than DEB. I'm even using it for application deployment with tito[1]. Even the software deployment story got better thanks to the Software Collections (https://www.softwarecollections.org https://www.softwarecollections.org). Rock solid base OS and an up-to-data application stack. CentOS on the servers + Fedora desktop is a great combination, since you can re-use your whole build infrastructure and skills for your workstations. [1]: https://github.com/dgoodwin/tito https://github.com/dgoodwin/tito

gtirloni 9y ago
Well, kind of up-to-date application stack. If you worry about security fixes, SL repositories don't usually have the latest versions. E.g. PHP7 repo still has 7.0.10 [0] Re: stability and QA, couldn't agree more. I only briefly used Ubuntu LTS in production back in '10 and it wasn't a fun experience. I'm sure it has improved but RHEL/CentOS (almost) never lets me down in that regard. 0 - https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-php-could-allow-for-arbitrary-code-execution/ https://www.cisecurity.org/advisory/multiple-vulnerabilities...
- bubblethink 9y ago
  >Re: stability and QA, couldn't agree more. While generally all LTS distros are quite good these days, I've found that, unsurprisingly, features that are developed heavily or owned by a single distro end up being rocky. RHEL has a lot of things that are not as heavily used elsewhere, and they are far from production quality. For eg., their lvm thin provisioning feature, is pretty rough, and had some very obvious failure cases that could even lead to data loss. I'm guessing that no one uses thinp in production.
  - lima 9y ago
    Please elaborate. I do use thinp in production (OpenShift + devicemapper pool as Docker backend, which uses thinp).
    - bubblethink 9y ago
      The default metadata pool size chosen by anaconda, at least up to RHEL 7.3, is paltry. Something like 100 MB for terabytes of data. Why they chose that is beyond me. Anaconda won't let you configure it manually during installation either. It'll get full in no time. Automatic extension is disabled by default. If you're lucky, you'll realize this by looking at your own logs. Then you'll try to extend it, at which point you'll realize that extending it won't extend the pmspare vol, and you've effectively disabled the pmspare functionality.
      - lima 9y ago
        Yes but that's well-known and documented. Including it in Anaconda looks like an oversight though (a thinp deployment needs to be well-planned and you'd definitely want to read the docs). There's a whole book-sized section about in the storage docs. The docker-storage-setup utility, for example, sets it up correctly and enables automatic extension.
        bubblethink 9y ago
        No, the use in Anaconda is perfectly legitimate. Docker aside, I use it for automatic snapshots. That's a fairly useful and unique feature that you can't have in any other legit way (not counting zfs, and btrfs is deprecated). There is also the yum-snapshot plugin that relies on it. It's not even that complicated. Just throw a few gigs at metadata and forget about extensions. If I have 2TB hard drives, I don't care if you use 16 G for metadata, which is the max.
cjsuk 9y ago
This. Our CentOS 6/7 deployment has been completely uneventful! Ubuntu going back to 10.04 LTS was hell.
ashark 9y ago
> QA is so much better. I had so many production breaking bugs with Ubuntu, especially on bare-metal. Is it (Fedora) much better on the desktop? I dumped Win10 a couple months ago to go back to Ubuntu for the first time since PulseAudio broke everything horribly and I swore off Linux on the Desktop forever (haha), and I was shocked to find that the UIs of both Gnome and KDE have if anything more rough edges than when I last saw them as far as usability goes, performance (UI responsiveness mainly) is generally mediocre to poor, and that both are at least as unstable/buggy as before (KDE significantly worse than Gnome in that regard, though neither's good). I'd consider jumping ship to an RPM-based distro for the first time since 2004 or so if the desktop experience is less... well, bad, frankly. Going back to Win10 isn't an option. What a garbage fire.
- noir_lord 9y ago
  Xubuntu to Fedora XFCE spin was entirely unexciting in terms of change, I like unexciting when it comes to the OS I use for my livliehood. Gnome 3 is still a dumpster fire and KDE got so bad as packaged that the devs felt the need to do Neon. KDE hasn't been good imo since 3 and Gnome since 2. I'm an XFCE user because of the Gnome 2 debacle though I've considered MATE a few times there isn't anything about XFCE remotely bad enough to make me seriously consider a switch.
- cjsuk 9y ago
  Gnome is just total garbage as is windows 10. They both drove me to OSX which I admit merely carries the crown of being "the least crap". I really want gnome2 back but fixed and as a first class citizen, not a fork that the big vendors wish would go away. That had some mileage.
  - davehtaylor 9y ago
    I love macOS. It's a Unix system, with a fantastic GUI, well-integrated applications, an ecosystem that is rich and vibrant, and a command-line system the is extremely usable, also with a rich ecosystem (homebrew, macports, etc) For me, after 10 years of trying to make desktop Linux work the way i wanted it to, macOS is everything I was looking for. Gnome decided that they had no desire to make a usable DE. They took everything that made it good, threw it out the window, and went as far as they could to make it unusable. KDE is just a clusterfuck. 2-3 system preferences panels, confusing options, and way too much gloss (glow, transparency, etc). I spent a long time with tiling window managers, trying to roll a system that felt comfortable and usable to me. And for the most part I succeeded. But the lack of integration with applications is really what ruined it for me. I want a good email client, an address book that can have arbitrary amounts of phone numbers and email addresses per entry, and the ability to give those arbitrary names. I also want my email, address book, and calendar to be aware of each other and play well together. I want a nice way to sync all of that to my mobile devices. I want an experience that feels coherent, instead of something hacked together with bailing twine. Don't get me wrong. I love Linux. For servers, I would never choose anything else (well, maybe FreeBSD). But it seems like over the last decade, distro developers and desktop environment developers have gone out of their way to sabotage their own efforts and make their software as unappealing as possible.
dima55 9y ago
I've had the opposite experience: compared to Debian, RPM distros feel like they were built by children. I guess YMMV :)
- deleted 9y ago
  [deleted]
dboreham 9y ago
In my experience they wax and wane. We're on our fourth distro in 10 years. Change has mainly happened because "it don't work with the new hardware we just bought". Currently on Ubuntu fwiw.
dozzie 9y ago
> RPM packaging is more fun than DEB. How so? From my experience, these two are equivalent to a high degree and don't differ much, and I've built a lot of both.
abrookewood 9y ago
Interesting - I did the exact opposite. Red Hat have a habit of removing packages that compete with their commercial offerings, which forces you to either compile from source or to install from other repositories - for example, they removed Apache ActiveMQ because they offer JBoss AMQ. This starts to become annoying because all of a sudden you have multiple update processes to keep everything up-to-date, whereas previously, you had one. After being bitten by this at least twice, I shifted everything to Ubuntu.

rodgerd 9y ago

Notable point: Red Hat are effectively declaring btrfs has no future. From the release notes: "The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux." https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

clem 9y ago
I wonder if they'll be supporting ZFS on Linux now that it's gaining momentum?
- ty_a 9y ago
  I highly doubt Red Hat will ever touch ZFS. Oracle and Red Hat have a very tenuous relationship. I hope Red Hat will support bcachefs though. I think it's the most promising alternative FS.
- mattl 9y ago
  Unlikely, given the license of ZFS and its incompatibility with the GPL
merb 9y ago
didn't they settled to xfs long ago? Isn't the default root fs on fedora xfs?
- bubblethink 9y ago
  Yes, btrfs was a tech-preview, meaning use if you want with no support or future guarantees. It has been officially dropped from future plans now.
  - lima 9y ago
    And they're working on adding CoW and deduplication to XFS.

flyinghamster 9y ago

One thing that is souring me on RHEL+clones is Red Hat's habit of yanking drivers for SAS and SCSI controller cards. On my home file server, CentOS 7 is the end of the line unless I buy a new HBA. Then there was the old Dell server at a customer's site that we were planning to use for a development/testing system. It had a perfectly functional PERC/4e RAID controller, but Red Hat yanked the driver in 7.0, never mind that Ubuntu Server works perfectly on the same hardware. We ended up picking up a cheap refurbished desktop to use as the development box.

lima 9y ago
Some examples would help. So far, any example of drivers disappearing that I encountered were due to quality issues.
- flyinghamster 9y ago
  The abovementioned PERC/4e is an example. The driver was deprecated in RHEL6, and gone in RHEL 7. The card in my home server is an Intel SASUC8I reflashed with IT firmware, so it's equivalent to an LSI SAS1068E. The driver for that is listed as "deprecated" in 7.
  - wyoung2 9y ago
    Another is the 3ware 8000 series. We got a dead machine in recently for repair and were faced with either moving the RAID drives and card over to a new server chassis while being restricted to the EOL'd CentOS 5 or upgrading to CentOS 7 but being forced to buy a 9000 series card and rebuild the array. Lose-lose.
    - lima 9y ago
      Well, I can see why Red Hat wouldn't want to support those old cards forever. Including the driver would be easy, but actually supporting it (QA, support...) is not. They already supported them for close to 10 years, which is much longer than most hardware lifecycles last nowadays (3-5 years). You could still build a custom kernel but yeah.

smegel 9y ago

Nice.

toyg 9y ago

Does it come with python3 installed by default, like recent Fedora?

Spiritus 9y ago
No. And it won't be until (at least) RHEL 8. It's available from SCL[1] and IUS[2] though. [1] https://www.softwarecollections.org https://www.softwarecollections.org [2] https://ius.io https://ius.io
carwyn 9y ago
It's also in EPEL now. SCL is cumbersome by comparison for basic usage.

apearson 9y ago

Anyone know how much a lag CentOS is normally behind Red Hat releases?

wyoung2 9y ago
About a month: 7.0: 4 weeks 7.1: 3 weeks 7.2: 4 weeks 7.3: 5 weeks Source: https://en.m.wikipedia.org/wiki/CentOS#CentOS_releases https://en.m.wikipedia.org/wiki/CentOS#CentOS_releases