Topic: changing PHP version : what are the risks ?

[jibe]

Hi,

I'm trying owncloud and I don't know why it was well working on my test server without any modification. But now, I try to install it on another server, and owncloud complains about PHP version, as announced in the wiki.

The given solutions are to change the PHP version, getting it in EPEL or webtatic-el5 repo. But with older versions of SME, it was said that it's dangerous to change the PHP version, and several people had security issues and/or successfull attacks doing that.

Is it really safe now to change PHP on a prod server ?

And if it's safe, once we have a more recent PHP version, could it be possible to install owncloud 6 ?

[stephdl]

Easy to do but you could have some noises after as if you do so (eg install version from webtatic or epel) you will have troubles with php53 package which is incompatible with our php version since is also php53 but renamed.
What i know about owncloud6 if you can exclude the security warning about the php5.3.3 it is the same requirement that owncloud5
For example after the upgrade of php you will have some dependencies errors if you want to install phpmyadmin from smecontribs.

[jibe]

Ok, I was surprised that PHP could be changed without problems !

But dependencies issues are not my main worry. What about security ?

[stephdl]

The problem is enough important, it won't be possible to install php contrib from epel or other repositories after the upgrade, about security, i do not know too much, only owncloud complains about this version of php, maybe the relevant php feature is used only for owncloud

[janet]

jibe

What about security ?

Of what ?
I think you are referring to the php5-cgi contrib, which over time did have a security flaw.
It was recommended to discontiniue using that as no one was releasing an upgraded (secure) version of the contrib.

As with all packages, if & when security issues are found, then usually they need to be upgraded.

If you need newer package versions immediately, then you are probably best to use sme9beta2, even though it is in beta it is quite good, it is based on CentOS 6 which is stable.

[stephdl]

not sure janet, actually the php version of centos6 is php-5.3.3-27.el6_5.i686.rpm, seems to me that the version required by owncloud is at least php5.3.4

[janet]

stephdl

My comment was a general one, meaning a user is more likely to find newer versions of packages in sme9, than will be found in sme8, so by using sme9 now, a user may be more likely to satisfy latest application dependency package requirements.

It could even be that a newer version of php is more "easily or readily" available for sme9, which does not cause problems with other application requirements. I have not yet looked or investigated re sme9/owncloud/phpmyadmin etc "issues".

I was just saying that if users want to use latest versions of applications, then using a "latest" version of OS will be a good/better place to start.

I do not think the ongoing issues of package dependencies will ever be adequately resolved, as OS"s & applications are always "leap frogging" each other, therefore developers are constantly having to catch up.
I think maybe the best answer is to use what works now, rather than wanting to use the latest & greatest.

[jibe]

Hi,

 

Thanks for the suggestions and explanations, but... could you please re-read my main question ?

owncloud complains about PHP version, as announced in the wiki.

The given solutions are to change the PHP version, getting it in EPEL or webtatic-el5 repo. But with older versions of SME, it was said that it's dangerous to change the PHP version, and several people had security issues and/or successfull attacks doing that.

Is it really safe now to change PHP on a prod server ?

So :

• Did I misunderstood what to do with those complaining messages due to a too old PHP version on SME ?
• If yes, could you please re-explain precisely what to do,
• If no, is there possible security risks in changing the PHP version for a more recent one ? It was the case with old versions of SME (and the reason why Firewall services proposed the php5-cgi solution, that was safer at this time than change the inside php version)

In other words : is it possible to have owncloud installed on SME without risks of security issues (other than the ones possibly introduced by a bad utilisation or config of owncloud itself), and how ?

Should I :

• Change the php version ?
• Keep the php version and find a solution (which one ?) so that owncloud doesn't complains ?
• Install an older version of owncloud (where can I find it, and will it be possible to have Mozilla Sync with it, and how) ?
• Consider that I have to choose between install owncloud (and sacrify the safety), or keep the safety (and not install owncloud) ?
• Other(s) ?

About dependency issues : I'm concious that changing php will have effects on some dependencies. I'm just hoping that they can be solved without too much difficulties, and that it will result in more recent versions of concerned packages, and so they will not appear anymore during the updates (as we have already an up-to-date or newer version). Did you talked about those "normal" issues, Stephane, or is there more (possible) trouble ?

Thanks.

[janet]

jibe

Owncloud 5 requires a specific version of php or newer in order to run correctly.
The comment in the wiki here
http://wiki.contribs.org/OwnCloud
says "Version 5.0.0. and later works out of the box on SME8", but I think that is not correct.
I think that may refer to an earlier version.

So in order for owncloud to run correctly without errors & security warnings, you do need to update the version of php.

The wiki states
"see bugzilla:7613 and most particularly bugzilla:7613#c3 and this one for a workaround. An alternative method is mentioned in the forums here. "
which has embedded links to various ways to update php.

One of those ways to upgrade php
(the forum post here http://forums.contribs.org/index.php/topic,50335.msg252984.html#msg252984)
uses the webtatic-el5 repo & does work OK (I worked it out), but another contrib (phpmyadmin) then complains of dependency issues if you try to install it. If you do not need to use that contrib then the php upgrade method appears to be a satisfactory & safe answer. No other problems have been mentioned in forums etc.
Personally I think the phpmyadmin contrib should be amended.

The php5-cgi solution was to allow different versions of php to run on sme server & to be selectively used by apps/contribs, ie the standard older php & the newer version php5-cgi, so as to avoid upsetting or creating dependency issues. It was the php5-cgi that became a security risk, NOT the standard installed version of php.
There is no security problem upgrading php to a later version eg as per webtatic or epel repos.

Yes you can install owncloud on SME, but you need to upgrade php first, & there will be no security issues (with or caused by php).
One dependency issue has been observed with phpmyadmin, so if you also want to install that contrib you will not be able to.

You can use an older version of owncloud on sme8 without needing to upgrade php, but you may be missing some features that newer versions of owncloud have.
I cannot answer if there is an old compatible version of Mozilla Sync as I do not use it.

The other choice is to NOT use owncloud, because of dependency requirements, & use some other app that is compatible with sme8 "as is".

If you upgrade php & install v5 owncloud you server is safe, but as you are then running a different version of php than what is in the sme server "base+updates", then you will need to monitor php security & ensure it is kept up to date if there are security releases etc.

The dependency issues re other contribs is not that easily solved.
As soon as users & developers digress from standard upstream sources, then there is substantial extra work to update packages & maintain good security, those other packages eg phpmyadmin have to be patched to work with newer version of php, so someone has to do that & follow up later when an even newer php version is released etc.

In my opinion it is better to stick with a standard SME server & only use contribs or apps that are compatible with the "base+updates" stream.
Part of that approach if you must use new contribs or apps that require newer versions of packages would be to start using SME9.
The final answer is not so simple & depends on your actual needs.

[mmccarn]

There is new information on owncloud & php 5.3.4 in bugzilla:7613#c18

[jibe]

Thanks a lot for those very clear explanations, janet 

Personally I think the phpmyadmin contrib should be amended.
[...]
One dependency issue has been observed with phpmyadmin, so if you also want to install that contrib you will not be able to.

Yes, or simply never used : we already have the mysql command, this clickodrome is useless and dangerous 
Just my opinion, but each time I say that, I get some more ennemies 
Anyway, I don't need that, so no problem for me.

If you upgrade php & install v5 owncloud you server is safe, but as you are then running a different version of php than what is in the sme server "base+updates", then you will need to monitor php security & ensure it is kept up to date if there are security releases etc.

Yes ! It's what I did not thougt and gave me doubts about safety in changing the version of php !
Probably it's also the reason why it was said formaly that it's dangerous to change the version of php ? And probably the successfull attacks were only due to a lack of monitoring of security updates of the new installed version ?

I'll have to think about that... Probably, it's possible to write some script to survey the updates automatically. Did somebody already did that (a complete script should send alarms and help for the update, or the standard update process should be modified...) ?

Part of that approach if you must use new contribs or apps that require newer versions of packages would be to start using SME9.
The final answer is not so simple & depends on your actual needs.

Exactly 
It could be the solution for my own server, but when it's a customer's server, we generally need more stability and security than a beta version can offer. So, the choice is often : install the contrib, modify some versions of package and find a way to follow the security updates, or not install that contrib...

And in this case (for owncloud 5), as said stephdl, SME9 cannot be the solution, as we should need to change the version of php anyway.

Thanks again. I'll think about a way to keep a new version of php up-to-date...

[jibe]

There is new information on owncloud & php 5.3.4 in bugzilla:7613#c18

Thanks for this information !

I had a (too much ?) quick look at the links, but it's not clear for me if the update will be a 5.3.4 version or a patched 5.3.3 version ?

In the second case, probably there will be no more risks with owncloud 5, but the dependency will always be php 5.3.4 and the warning will stay, is not it ?

In another way, as soon as we change the version of php, we could get the more recent one and use owncloud 6. Am I wrong ? (I didn't look at this possibility very well...)

[mmccarn]

Since the owncloud error specifically mentions CVE-2006-7243, and since the recent patches to php 5.3.3 specifically address CVE-2006-7243, I think the owncloud error will go away.  If the warning is based on a vulnerability test being run by the installer, it may go away immediately; if the warning is based on a simple version check, then possibly not until after owncloud releases an update that amends the version check they are running.

Owncloud 6 works on my SME 8 server.  Owncloud 6.0 would not run or upgrade, but I tried a fresh install of Owncloud 6.0a and had no problems.

The PHP warning is worded differently in Owncloud 6, and doesn't mention the null byte vulnerability (CVE-2006-7243):

Your PHP version is outdated
Your PHP version is outdated. We strongly recommend to update to 5.3.8 or newer because older versions are known to be broken. It is possible that this installation is not working correctly.

[janet]

Jibe & mmccarn

Refer to this post.
http://forums.contribs.org/index.php/topic,50335.msg253600.html#msg253600

When I downgraded php back to standard, owncloud (5) "ran" without apparent warnings, but there were many errors appearing in the admin panel section. The contrib is making many php calls that the older version of php does not appear to support.

So it seems that using anything less than the recommended php 5.3.4, will cause owncloud to NOT work correctly.

Have not tried owncloud 6 yet.

[jibe]

Hi,

Happy new year to everybody 

Yes, janet, I saw the post. I think that it's better to not go back and forth with PHP versions. I'm trying to create a cron job to send warnings for PHP updates in the webtatic-el5 repo, so that we can keep without risks keep this version and maintain it up-to-date easily.

About owncloud 6, I did not paid attention, but seems that it's still a beta version ? I feel it strange that the "official" list of addons contains some ones needing owncloud 6 if so... Anyway, I'm not running after the newest versions and owncloud 5 is good for me, so I'll not use owncloud 6 for now.

Studiying how to manage the updates with webtatic-el5, I see, janet, that your method described here lets some garbage in php-pear :

Code: [Select]

#yum --enablerepo=webtatic-el5 check-update php*
[...]
php-pear.noarch                           1:1.9.4-1.w5              webtatic-el5
Obsoleting Packages
php-pear.noarch                           1:1.9.4-1.w5              webtatic-el5
    php-pear-XML-Util.noarch              1.1.4-3.el5               installed   

I don't like that so much  Probably, we should also update this ?

I tried on a test server. Seems to work well :

Code: [Select]

yum update --enablerepo=webtatic-el5 php*
[...]
================================================================================
 Package         Arch          Version                Repository           Size
================================================================================
Installing:
 php-pear        noarch        1:1.9.4-1.w5           webtatic-el5        433 k
     replacing  php-pear-XML-Util.noarch 1.1.4-3.el5


Transaction Summary
================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 433 k
[...]
Running Transaction
  Installing     : php-pear                                                 1/3
  Cleanup        : php-pear                                                 2/3
  Erasing        : php-pear-XML-Util                                        3/3

Installed:
  php-pear.noarch 1:1.9.4-1.w5                                                 

Replaced:
  php-pear-XML-Util.noarch 0:1.1.4-3.el5                                       

Complete!

After that, owcloud seems to work well. But it will not be easy for me to make more complete tests, unless I do that on a prod server...

As it's a more recent version of php-pear, I think that it should not break anything and that it's better to update it than keep the obsolete package with the new php version (5.3.28-2.w5 for me today).

Any comment ?

[janet]

jibe

Studiying how to manage the updates with webtatic-el5, I see, janet, that your method described here lets some garbage in php-pear :
yum --enablerepo=webtatic-el5 check-update php*

No I did not say that (php*), I said
Then run the php 5.3.27 yum update
yum update --enablerepo=webtatic-el5 php

ie just upgrade existing php package & any required dependencies will also be installed.
By saying php* you are instructing that all php-something packages will be installed/upgraded, which as you say let's in some "rubbish".

Generally speaking if you need newer versions of packages or additional packages to satisfy dependency issues, that is OK to do, I would just say do not upgrade everything as you will likely run into problems somewhere.
SME server is a set of tightly integrated packages that are designed to work together, the more changes you make from "standard" the more risk there is that something will break.

[jibe]

Yes, I understand and agree with all that. More : your last sentence was the reason why I initiated this post !

However, when you only upgrade php (and not php*), dependencies will be also installed/updated. So, you have those packages changed :
php.i386                                  5.3.28-2.w5
php-cli.i386                              5.3.28-2.w5
php-common.i386                      5.3.28-2.w5
php-devel.i386                          5.3.28-2.w5
php-gd.i386                              5.3.28-2.w5
php-imap.i386                           5.3.28-2.w5
php-ldap.i386                            5.3.28-2.w5
php-mbstring.i386                      5.3.28-2.w5
php-mysql.i386                          5.3.28-2.w5
php-pdo.i386                             5.3.28-2.w5

So, later, you could have some update on anyone of these. So, if I'm not wrong, we will have to check for updates not only the php package, but also all of them. This is the reason of my php* in my check-update.

Anyway, even without the joker "*", the result is almost the same :

Code: [Select]

yum --enablerepo=webtatic-el5 check-update php
[...}
Obsoleting Packages
php-pear.noarch                           1:1.9.4-1.w5              webtatic-el5
    php-pear-XML-Util.noarch              1.1.4-3.el5               installed   

So, I'm asking what is the best : leave those packages as is even if they are obsolete with the new version of PHP, or update them ?

In the first case, it's risky because those packages are not done to work together with the new installed PHP, in the second case it's risky because it's more packages changed and not done to work with standard packages on SME...

What is the less risky ???

[janet]

jibe

What is the less risky ???

I thought I answered that, make the least number of changes possible compared to a standard sme server.

In particular re upgrading php from webtatic, then only change the packages that php requires as dependencies, & those were the ones shown in my original post.
My testing did not show issues with php-pear etc, maybe your server is configured differently &/or has other packages installed that require php-pear etc etc.

[jibe]

I thought I answered that

Yes, you did ! I was just not sure that you considered that keeping an old library that is obsolete with the new version of PHP could also be risky...

You're very right when you say that we must do as few changes as possible, and it's what I do (and advice) generally. But in another hand, I'm still afraid that, in this case, it's just doing things by halves and that it could be dangerous...

My testing did not show issues with php-pear etc, maybe your server is configured differently &/or has other packages installed that require php-pear etc etc.

Yes, I did not paid attention, but I have not that on others servers... Probably, it's just because I made a lot of tests and trials on this one...

So, finally, it's probably a useless question... sorry about that 

[stephdl]

Do not apologize too much on this post, if is see the comment 18 of bug 7613 redhat has released an update against some flaw in php. The update is available in centos, but not for sme, probably a question of days, or weeks

It is a good new

[jibe]

Hi,

Yes, Stephane, but :
1 - "probably a question of days, or weeks"... if all goes well. But it could be longer, or not work as well as expected, or work for owncloud 5 and no more for owncloud 6 when it will not be anymore a beta version. So, it's good to have another solution.

2 - The problem of the version of PHP is recurrent on SME. Now, with version 5, it is less critical than with SME 7x, but there has always been a lot of people asking how to change the PHP version on SME. I initiated this post because I have a special need now, but also because what is discussed here can be useful for others cases

[stephdl]

please see see http://bugs.contribs.org/show_bug.cgi?id=7613#c21 it seems that we have made a mistake about the right version of php package but updates are inside.

For the late in php version ,the fault is on the redhat side, not really on SME side, however we need to get sooner sme9 but the team in bugzilla is really thin, and we need Troubleshooters, with the hope that a day they become developers

[jibe]

(self-censored : useless question)