PHP Version Not Enough For Developers

Home » CentOS » PHP Version Not Enough For Developers
CentOS 41 Comments

Hi,

So, it seems that the current version of PHP in CentOS 7 is PHP 5.4.16
however this version of PHP stopped getting security support from the PHP
people one month ago [1].

Now, our developers want to use the new and shiny PHP because they want to use the latest version of Zend. They are proposing using this package [2]
but I never heard of this repo.

Other than building the packages ourselves is there a more acceptable way to run a later version of PHP?

Thoughts? Experiences? Ramblings?

Ta,

Andrew

[1] – http://php.net/supported-versions.php
[2] – https://webtatic.com/packages/php56/

41 thoughts on - PHP Version Not Enough For Developers

  • I’m personally not a fan of the webtatic repository. This is mostly due to the number of users on irc who seem to have problems with it. I would recommend either the upcoming software collections packages or the IUS
    repository packages. https://iuscommunity.org/pages/About.html

    IUS has been a very good/reliable way to get more recent versions of things, and the folks responsible for it are active both on irc and in the mailing lists.

  • For me it sound like an example of the difference between “bleeding edge”
    and “enterprise” systems. The first is what developers most often like, the second is what humble sysadmins prefer as they have to keep something developed long ago running for as long as possible – and without crashed, daemons dying etc (== “bleeding” which always accompanies “bleeding edge”
    anything). Sorry for venting my own usual pain here…

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Valeri Galtsev wrote:
    Add another of that opinion. All the years that I did development, I never needed bleeding edge, and I’ve done a lot. On the other hand, if the spec said the current version would support something, it *better*, because, sooner or later, I’d find a need to use whatever.

    Bleeding edge never supports that NEWSHINY without breaking…. Like the team lead, now years gone, who built a project here in ruby on rails… and was constantly *terrified* when I wanted/needed to update the servers that was on, and stayed on “enterprise version whatever”, without current updates…. Things like that are what I refer to as fragile….

    mark

  • I’ve been using IUS in the past. They have a good way of naming their rpms, so they don’t interfere with the RH rpms. But they don’t support older CentOS versions still on extended support as long as I needed them. And they don’t provide as much php-related rpms (f.i. pecl-stuff) as remi does. So, with newer PHP versions I had to go to remi’s repo. Combined with EPEL
    (and rpmforge being dead, anyway) it’s working quite fine here for PHP 5.5
    and 5.6. He provides files for CentOS 5, 6 and 7. The only caveat is that he uses the same rpm names as with the original ones. So, you have to give this repo the same priority as the base repo has. In consequence you have to be careful what it wants to install as dependencies and exclude a package sometimes. But all in all it works very well.

    I’ve used the webtatic repo once for a special case. I don’t know exactly why but I wouldn’t recommend it.

    If IUS provides the version you need I’d go with that.

    Kai

  • Nux! wrote on Thu, 22 Oct 2015 17:27:26 +0100 (BST):

    Exactly. Nevertheless, PHP 5.6 is not “bleeding edge” as someone else said. 5.5 and
    5.6 are really state of the art and often necessary to install certain software packages or for some functionality. The packages provided by RH
    are much too fast outdated or have other problems. It’s a reality.

    Kai

  • Kai,

    It is a reality, but when you look at the RHEL target audience, it’s not exactly hip devs deploying Docker in the cloud. Big corps, banks and the like have a very slow development cycle and long term support is absolutely crucial, software needs to run for years on end without glitches, without interruptions, in a very predictable manner etc.

    For the aforementioned devs I think the best answer are the software collections, that or just use a different distribution. It is what it is.

    Lucian

  • 5.4.16
    PHP
    [2]
    the second is what humble sysadmins prefer as they have to keep something CentOS should change the php version more ofthen. I dont uderstand CentOS 6, its still using php 5.3, who got EOL a year ago… I had to switch to another repo to get this (to not get the headache by compile by hand). this is under active development now. topic, they are the ones who really knows PHP

    This yet once more exemplifies the point I was trying to make. If I build new system (with new components of end point software using, say PHP), then I would pick the latest stable version of PHP. Exactly as you are point out. And I prefer to roll new box out with all latest stable everything. From this point on, once I have the box in production, I often have no luxury (when time goes by) to upgrade some components other stuff needs to run with. Like PHP that will be latest stable 3 years down the road will be several minor versions up, and some of my end components may not run with it as some internals may have changed. At this point it is exactly what I am trying to stress: either I break things that I have no newer version that works with latest version of PHP, or I can stay with older version of PHP – if at all possible. This is basically the difference between, say, Debian (and clones) style of updates/upgrades
    (when update bring you new version of package) and RH Enterprise Linux which keeps older version (thus preserving all internals), and [doing tremendous job of] backporting security and bug fixes implemented in new version to older version. At least this is what we loved about RHEL – not quite sure to what extent it still is true recently.

    The best example of really troublesome compatibility would be python and modules for it. To my python developers and users I call python a “sneaky snake”. Whoever worked with python and modules written for it knows what I
    talk about: you always beed to match versions of modules rather rigorously the version of python itself, or things will not work. There is, however excellent “Enterprise” piece of software written in python: mailman. I
    really never had any trouble of any kind with mailman. This is what I
    figure Mark meant when he said you can write software which will work with big range of different versions of whatever it depends on – he is (was?)
    developer, he knows what he is talking about.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I would point out that Red Hat backports items to RHEL-7 (and we therefore backport those into CentOS-7 when we rebuild the source code).

    I would also point out that the developers who ignore RHEL then ignore getting their code into enterprises that use RHEL. Being that those enterprises are the people PAYING for Linux, it MIGHT be the brightest idea for those developers to write code that they expect to be paid for for non-enterprise distributions :)

    That said, software collections is one way to get newer development tools and we should have more software collections, including a newer version of php, very soon in CentOS-7.

    The collections will go here when ready:

    http://mirror.CentOS.org/CentOS/7/sclo/

    Right now only a couple of things there. Will be more soon.

  • Correct .. but that is not who RHEL, CentOS, Ubuntu (LTS), or SLES type distros are for. That is what Fedora, OpenSUSE, Ubuntu, Debian, Linux Mint and any other number of “Bleeding Edge” distros are for. If you want latest and greatest .. well, then use latest and greatest. If you want enterprise, then use CentOS.

  • And incidentally these 0.01% (even if the number is true) of Enterprise users pay virtually 100% of RH income (the last is what the brilliant job of individuals at RH is paid for from). Let’s not forget they as well as us have families to support.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • But you don’t seem to understand CentOS.

    The packages in the main repo aren’t maintained by ‘CentOS package maintainers’. They are rebuilt from RHEL source packages. If you’ve got a complaint with the version, complain to Red Hat. As other have explained in this thread, you should expect considerably longer support from Red Hat (and thus CentOS) for any release of PHP than you’ll get from upstream PHP.

    Sure, if you don’t care about having a product continue working after a couple years, go ahead and build the upstream version of PHP and manually apply security updates yourself. Maybe you can pay the PHP
    developers to support it for you, since they really seem to know PHP.

    If you want to have a stable platform to deploy your web service, use an enterprise operating system like CentOS.

  • that suggestion would have to be made with RH, not CentOS, as the default CentOS package list *IS* the RHEL package list.

  • I would add to software collections you mention and different Linux distributions (differing in update/upgrade lifecycle scheme) also other
    *nix-es, FreeBSD was one someone mentioned already (I too “half-moved”
    servers to it), but there are many other choices of systems. Still, disregarding the part some of us dislike personally (plus often reboots necessary to install some vital updates – which all Linuxes are prone to beginning somewhere around 2.6 kernel) I would say I really admire the great job RH folks are doing – and definitely tremendous job CentOS
    maintainers do!

    Just my 0.02

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I
    must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.

    Apparently it is the later.

  • I regret James cut out positive part I said – about great job both RH and CentOS teams are doing!

    But coming back to negative part (which is about almost any Linux distribution). These often reboots started in my recollection around 2.6
    kernel which is long ago. Already then one of my friends started calling Linux “Lindoze” apparently stressing you need to reboot it often, like MS
    Windows. I would suggest to take his label with a grain of salt, as he is the one who also used funny name for another well known system, after Oracle bough out Sun Microsystems he called Sun-Oracle “snorkel” (as if you pronounce it awfully fast).

    This was what made first step to “similarity” at least in one respect of Linux to MS Windows. Is systemd yet another step? No comment from me, as at some point I decided to not be on any side of apparently awfully polarized on this issue community. ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • There’s no way that needing a reboot is related to 2.6. Indeed newer features like ksplice can /reduce/ the number of reboots required.

    jh

  • I always admire the “creative trimming”. You can really quite shift what one tried to say. The above is _not_ the point I tried to make! ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • No. If anything, systemd handles upgrades better than SysV init, since it handles re-execing better. Please stop spreading FUD.

    Most likely the glibc and openssl updates are what people are talking about. Doesn’t require a reboot, just restarting all the services that might have those libraries loaded.

    —
    Jonathan Billings

  • and of course, new kernels generally require a reboot, unless you’ve got that live kernel update thing running (which scares the heck out of me).

    —
    john r pierce, recycling bits in santa cruz

  • Jonathan Billings wrote:

    What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what’s going on, just worked or didn’t, so I don’t know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It’s much less informative in most ways in helping me solve problems.

    mark

  • Well, looking back, during kernel 2.6 there was no systemd at all. But! That was the time where udev and dbus came into the boot cycle.

    IMHO, the intrinsics between glibc (always a cause for refresh of initrd and full reboot) and udev where the start of the “reboot often”.

    Later on came dbus from the pure app-message-bus to the monster (kdbus?)
    that it is now, adding in its own dreg of dependencies and making the boot cycle unclean in itself.

    The mess we have now, is not the work of just one change.

    What was the rationale to get udev into boot? — Handling the ever changing mess of plugable, switchable hardware. Not born and bred for servers, but for mobiles (phones, tablets, laptops).

    Who was the one that decided that “one-size-fits-all” and put that into server environment?

    What was the rationale to let dbus near the system start at all?
    — Again mobile development.

    Same as before who was the one that thought, “nice, lets fuck up the servers even more with that”.

    Systemd was just the latest development, and not the worst. Yes, it could have gone better, and some of the devs have had more head-in-the-clouds than feet-on-the-ground.

    Looking back, systemd is the only “big” change since 2.6 that makes sense for servers. It’s surrounding scene, however, does not make much sense for servers. Journald is a mess, but solveable

  • Jesus Christ .. do we really have to start ANOTHER systemd thread.

    For the sake of everyone’s sanity .. if you (any user, not mark specifically) don’t want to use systemd, then please don’t use CentOS-7. CentOS-7 contains systemd and where ever Red Hat puts it, CentOS will rebuild the source code.

    If people don’t like the distro, then use something else.

    These lists are for providing USEFUL information to CentOS users .. flame threads will result in list users who are moderated.

  • Was it? Many servers are deployed as standard images, both physical and virtual, and having a single, standard, cloned image boot easily on multiple types of hardware makes lots of sense in this environment.
    Dbus is about hardware enumeration, both cold and hot plug. And there are servers with hotplug PCIe, even hotplug CPU’s. Dbus makes hotplug HDD support smoother, for instance, and hotplug isn’t limited to USB or firewire (eSATA and external SAS, even fibre channel, can be hotplugged in most cases).

    I still remember having to rebuild initrds when moving a clone from a server with one type of disk controller to another. It should work a lot better with dynamic hardware detection in the initrd. (I wont’s say it’s prefect, because I haven’t personally tried every possible combination of hardware, but it has worked lately when I needed it to work.)

    A SAN storage processor, for instance, must be able to hotplug drives, enclosures, front end and back end interfaces, power supplies, and sometimes even processors while staying up.

    I would agree.

    Better hardware support, ease of virtualization (as a guest and as a host), and dynamic hardware detection for rapid redeployment/hardware upgrade, just to mention three.

  • For example, you could help out with Devuan, which aims to remove systemd from Debian, or you can switch to Slackware, one of the few major distros not to even include systemd (so far).

    Johnny, thank you for your efforts in trying to keep the mailing list on-topic. :)

    –keith

  • Yamaban wrote:

    IMHO agreed. I believe that there is a perceived convergence of “needs”
    between (call it…) more-mobile personal linux and _virtualised_ server linux. If we can create a linux VM in under 5 minutes, “we” expect that it will boot-up without the sys admin’s intervention. Then “we” expect that we can migrate it to newer hardware without manual reconfiguration.

    But returning to PHP: If apps are developed without real separation between user interface and back-end, then the back-end will be victimised by the relative and inherent instability of the front-end. The web servers then really become part of the front-end and must be handled as such. I would argue that this lack of separation between front-end and web server is a feature of the WWW
    and its protocols, we cannot escape it. So no surprise that most data centers leave the web servers outside or mostly-outside the network perimeter.

  • Or switch away from Linux, say, to (Free|Opnen|Net|PC-|…)BSD just to expand options. But to take advantage of the greatness of RHEL and CentOS
    life cycle you have to live with systemd and friends no matter what you thinks about them (you see, I already have convinced myself ;-).

    And yes, thanks for everybody’s effort to keep discussion off the insanely polarizing us topic(s).

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I am quite happy even for there to be a SIG to modify CentOS-7 to not require systemd and creating a variant of that branch. Those discussions (if enough volunteers were found to staff the SIG) would take place on the CentOS-Devel mailing list.

    But what is of no use to anyone is another 500 mail flame thread about systemd being the devil.

  • specifically) don’t want to use systemd, then please don’t use CentOS-7. systemd from Debian, or you can switch to Slackware, one of the few major distros not to even include systemd (so far). expand options. But to take advantage of the greatness of RHEL and CentOS
    thinks about them (you see, I already have convinced myself ;-). And yes, thanks for everybody’s effort to keep discussion off the insanely require systemd and creating a variant of that branch. Those take place on the CentOS-Devel mailing list.

    I would be very interested in that. Not as a developer which I am not, but as an end user (or almost end user as I am sysadmin ;-) If that happens, will there be announcement on CentOS@CentOS.org list or I should subscribe to CentOS-Devel mailing list?

    Valeri

    systemd being the devil. on-topic. :)

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Yes.

    Let’s get some information that might be useful:

    Are binary logfiles an inherent part of systemd?
    If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.

    Is the aforementioned dearth of information an inherent part of systemd?
    If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.

    The evil of binary journals for people is fairly cut and dry. If data is only for another program, making it binary when it could easily be text is against unix philosophy and a bad design choice, but not proof of evil. When the data is text specifically to be read by people, choosing to make it binary is evil and rude.

    E.g. Johhny Hughes?

    What do threat posts result in?

  • All of that might be true, however this is not the place to discuss that.

    The goal if CentOS is to exactly build RHEL’s source code. We do that. If that is not what you want in a Linux distribution, then CentOS is not for you .. that is just the facts.

    We are not going to change something that is designed a certain way in RHEL source code.

    So, that means that the place to have those discussions is not on a CentOS list, but on a list where something can be done about it. On the list where the code is actually developed, on a Fedora List or a RHEL list.

    That is not a threat, it is a promise. I set the moderation bits on the list. I get dozens of emails off list asking for people to moderated on the flame fest emails.

    We should all be adult and professional enough to understand that designing of software happens somewhere else and endlessly complaining about it here does nothing to get it fixed. It just annoys users who want to use CentOS and get help using it.

  • Johnny,

    Thank you for providing this service to the community! I can understand why people are upset about systemd, but this isn’t the place to rage about it.

    — greg

  • From https://lists.CentOS.org/mailman/listinfo/CentOS :

    Of course this is the place to whine about systemd threads when journalctl is under discussion.

    The contents of /etc/ssh/ssh_config ?

    Other post-install modifications are certainly possible. A demon that continuously makes text copies of the journalctl logs?
    A replacement for journalctl?

    Call it a promise if you want. Denying that it is a threat is a bit much.