3 ms·

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

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.
        lima 9y ago
        LVM snapshots are really slow though.
        bubblethink 9y ago
        That's the whole selling point of thinp (at least for root and home). They are supposed to be faster than regular snapshots.
  - alangibson 9y ago
    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.
    - jsiepkes 9y ago
      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.
    - ibotty 9y ago
      ... which is now supported by rhel!
lima 9y ago
For PHP, you'd want to use IUS instead: https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/development.languages.group.html https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/r... Source repo: https://github.com/iuscommunity-pkg/php71u 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).
- bubblethink 9y ago
  How does this compare to remi's repos ?
  - level3 9y ago
    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.

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.
      - lima 9y ago
        LVM snapshots are really slow though.
        bubblethink 9y ago
        That's the whole selling point of thinp (at least for root and home). They are supposed to be faster than regular snapshots.
- alangibson 9y ago
  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.
  - jsiepkes 9y ago
    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.
  - ibotty 9y ago
    ... which is now supported by rhel!

lima 9y ago

For PHP, you'd want to use IUS instead: https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/development.languages.group.html https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/r... Source repo: https://github.com/iuscommunity-pkg/php71u 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).

bubblethink 9y ago
How does this compare to remi's repos ?
- level3 9y ago
  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.