For PHP, you'd want to use IUS instead: https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/r...

Source repo: https://github.com/iuscommunity-pkg/php71u

For security reasons, I'm directly building the packages from Git. Works like a charm, and I don't have to include many different third party repos or introduce additional security dependencies.

Generally, Red Hat backports security fixes without incrementing the version number (though that doesn't seem to be the case here).

How does this compare to remi's repos ?

Personally I prefer remi because package names are kept the same, making it easier to upgrade. With IUS, the version is part of the package name (i.e. "yum install php71"), which tends to make maintenance and configuration messier.

>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.

Please elaborate. I do use thinp in production (OpenShift + devicemapper pool as Docker backend, which uses thinp).

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.

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.

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.

LVM snapshots are really slow though.

That's the whole selling point of thinp (at least for root and home). They are supposed to be faster than regular snapshots.

The fact that RHEL recommends (recommended?) thin pool is malpractice. When deleting containers, the storage is never released. If you create lots of new containers, doing batch processing for instance, you will eventually exhaust the storage capacity even if you are extra careful to always garbage-collect the dead containers.

We switched to overlayfs and never looked back.

Storage with docker is just such a mess. In the end I went for Triton (SmartOS) which has ZFS and docker support and never looked back.

... which is now supported by rhel!