Author
|
Message
|
Michael Kress
|
Thursday 15 February 2007 11:02:16 pm
Hi Folks, I'm using centos-4.4 which comes with php-4.3.9. The eZ Publish 3.9.0's requirements tell me to use php-4.4, but that version is not available in any of the centos standard rpm repositories. As I have to be compliant with the repos, compiling php will be no solution for me. Anyways, I tried ez publish on centos-4.4/php-4.3.9 and it works, obviously. Now I'd like to ask you about your experience. Is it ok to use that combination or will it fail in some aspects? Regards, Michael
|
Betsy Gamrat
|
Friday 16 February 2007 5:06:06 pm
Michael, You really need PHP 4.4+ for eZ 3.7+. When we upgraded from PHP 4.3 to PHP 4.4, eZ 3.6 could not run, and eZ 3.7 could not be installed on PHP 4.3. I would recommend complying with the requirements. http://ez.no/ezpublish/requirements
|
kracker (the)
|
Saturday 17 February 2007 10:08:07 am
Michael, Betsy is correct in her portrayal of the eZ publish requirements. I too have seen first hand the very same description of events surrounding my first related experience in this subject. While you might be able to do just about anything, doesn't mean that it's a good idea. It sure sounds like you might want to build the software you require as packages for your operating system in the absence of supported packages. While I've not done this, compile php and build rpm of the package for the actual installation. While I opted for source base installation directly, you can build an rpm package yourself.
<i>http://www-128.ibm.com/developerworks/library/l-rpm1/</i>
<i>http://www.netadmintools.com/art272.html</i> <i>http://www.google.com/search?q=building+your+own+rpm+packages&btnG=Search</i>
hth,
//kracker <i>kmk - party ... "a party, a party we goin' to a party ..."</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|
kracker (the)
|
Saturday 17 February 2007 10:18:53 am
I've added a stub node in eZpedia on this subject, http://ezpedia.org/wiki/en/ez/creating_rpm_packages Feel free to add to it ...
//kracker <i>mc chris - dungeon master of ceremonies - blastic</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|
Michael Kress
|
Tuesday 20 February 2007 4:47:53 am
Hi, thanks for the replies, I know how to compile php and I know how to build an rpm, but it all takes longer than executing a simple
yum update
It's not only the 10 minutes it takes to compile and install the package, it's moreover the inclusion of the distribution specific patches, the testing of the package, etc. Which may take much longer. Caring for about 10 servers I can't afford this amount of time each time a php update is available.
I may quote Johnny Hughes from http://lists.centos.org/pipermail/centos/2007-February/075433.html : "The best bet is to fix the app (mk:Johnny is speaking of ez publish here) that requires php 4.4 or to find/build an RPM for php-4.4." Apart from the question "who should fix it's package", my 2ct about the word "enterprise" ... "Enterprise (stability)" means to me: to have well tested patches and binaries installed and running. "Well tested" means to me: I don't want my customers to be obliged to test that stuff and to unintentionally become crash test dummies. I may help ez community by providing a working php.spec, that should not be a big problem, but I can't maintain that stuff, that's my personal time problem. I may even be conviced about such an rpm (as soon as it exists) being <b>THE</b> solution for using ez publish, but how are you going to tell all the centos and RHEL users to be obliged to use another php rpm as soon as they want to use that particular cms? How are you convincing them to move away from their standard repositories and to risk things? That should be the more hairy part... IMHO the real solution would be to identify the real reasons for having 4.4 as a requirement (bug#1: "loops under condition xy", solved as of 4.4, bug #2: "if statement not evaluating correctly", solved as of 4.4, ...). What I could contribute as a complimentary information is to identify which of these bug fixes have been backported to the php rpm binary as provided by RHEL. Examples from the php change log from RHEL: * Di Sep 26 2006 Joe Orton <jorton@redhat.com> 4.3.9-3.20 - add fix for php_error varargs use (#199947) * Sa Sep 16 2006 Joe Orton <jorton@redhat.com> 4.3.9-3.17
- add security fix from upstream: CVE-2006-4484 - add metaphone() fix (#205714) Sounds a bit as "much work", but imagine the opportunity for ez publish to be able to be installed on numerous RHEL installations!
Regards, Michael
|
Björn Dieding@xrow.de
|
Tuesday 20 February 2007 6:07:11 am
The real reason for the php4.4 requirement is the bogus php4.3. The is a certain bug in php, which we call the "Reference Bug". php4.4 and php4.3 are not the same. A backport of this php bug is most likely not possible. I am more or less quoting Derick here.
In any case: I see having php4.4 rpms as the solution to your problems. Debian does do this job quite well :-)...
Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/
|
André R.
|
Tuesday 20 February 2007 7:00:16 am
To read more on it you can also read the PHP 4.4. Release Announcement: http://php.net/releases/4_4_0.php From dr: running eZ Publish 3.7+ on PHP 4.3.x could potentially lead to data corruption.
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
Derick Rethans
|
Tuesday 20 February 2007 11:25:45 am
"A backport of this PHP bug is most likely not possible." that is correct, as a backport would result in a PHP 4.4 again. The jump from 4.3 to 4.4 was made because this bug fix caused binary breaks in PHP's API - which is not really important at all for users - but some distributions insist on staying with old and buggy versions of PHP unfortunately because of this increase in minor version number.
|
Michael Kress
|
Wednesday 21 February 2007 6:00:27 am
ok, agreed, it's clear that the "Reference Bug" can't be backported. Well, sad, but I have to be creative in searching for another solution.
Anyways, thanks for providing the hints, I can't run into danger of losing data, just because ez publish doesn't fit into my installation(s), so this thread was useful to me anyways.
Have a good time Michael
|
Brett JB
|
Tuesday 06 March 2007 1:05:17 am
@Björn Dieding@xrow.de
<i>In any case: I see having php4.4 rpms as the solution to your problems. Debian does do this job quite well :-)...</i> Greetings. I am new to EZP and currently run Debian, whereby PHP 4.4 is not yet a 'stable' package. Of course, considering I have other websites hosted on this server I am reluctant to install the testing package due to the other testing dependencies it may have. Do you have a suggestion as to getting PHP4.4 running safely on Debian?
Thank you.
Regards, Brett
|
Michael Kress
|
Tuesday 06 March 2007 2:12:18 am
I'm not (anymore) averse to using debian. As soon as somebody can recommend me system x or system y I'll consider taking it as a base as soon as it may be used as a XenU guest on a x86_64 machine. I already got a debian system running, I'll think about it, but I'm still open for more suggestions. Folks, what do you use? Cheers - Michael
|
Xavier Dutoit
|
Tuesday 06 March 2007 2:14:06 am
http://www.dotdeb.org/ X+
http://www.sydesy.com
|
Michael Kress
|
Tuesday 06 March 2007 5:03:18 am
Ah bon, c'est intéressant, je vais le régarder! Merci!
|
Heath
|
Friday 09 March 2007 2:29:02 am
I found an article on eZpedia,
it was recently updated to include how to build a custom php rpm.
It even covers doing this for suse and centos. For those who need custom rpm instead of deb <i>http://ezpedia.org/wiki/en/ez/creating_rpm_packages</i>
Brookins Consulting | http://brookinsconsulting.com/
Certified | http://auth.ez.no/certification/verify/380350
Solutions | http://projects.ez.no/users/community/brookins_consulting
eZpedia community documentation project | http://ezpedia.org
|
Michael Kress
|
Friday 09 March 2007 3:13:10 am
wow, that's perfect - thanks for the link!
I hope, someone will include a lib64 patch for x86_64 some time. I haven't tried the above link, but I'm in doubt that the thing will compile. It's quite weird, even the plain tar.gz doesn't compile on my x86_64 because of lib64 issues (the config.m4 files aren't prepared).
Greetings Michael
|
Denis Zatsarinny
|
Saturday 10 March 2007 10:07:57 am
Hi For CentOS and all RHEL/Fedora based distros use http://dragon.linux-vs.org/~wensong/packages/mysql-php/
|
kracker (the)
|
Saturday 10 March 2007 10:52:58 am
While I do appreciate Denis Zatsarinny's contribution.
I urge users not arbitrarily use another's (binary or otherwise) packages (so lightly). I would not use them in production. And for as little time as it takes to build your own ... I urge users to use tools to build the sources themselves rather than trust random packages. It's not that hard to build the source and it is much more effective and secure. <i>//kracker CHAMILLIONAIRE - Ridin ...</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|
Michael Kress
|
Sunday 11 March 2007 12:30:30 am
Dragons' php package: fails to build on x86_64. The only package I got compiled was http://www.interworx.com/forums/showthread.php?p=11431 but it failed to compile 4.4.6, the patches don't apply correctly.
|
kracker (the)
|
Sunday 11 March 2007 3:54:04 am
I did hear in passing from Zurgutt that he had x86_64 binaries of some form for php 4.4.x at the end of last week via #ezpublish irc (on freenode.net). Perhaps, if this is what your looking for specifically ... One might be able to comment offhand on how to overcome the breakdowns experienced by others in the community and reach this goal. <i>//kracker Kottonmouth Kings - Life Rolls On</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|
Michael Kress
|
Sunday 11 March 2007 5:48:23 am
Hi, sorry my information was a few days old, I just took the carat SRPM, replaced the 4.4.4 tar.gz by the 4.4.6 one, changed the version line in the php.spec and did a rpmbuild --with cos php-interworx-4.4.6.spec -ba
The build went through! I think the first time I didn't issue an --with cos. Moreover I installed a few other libs, so maybe, that's it now ...
I installed the resulting binaries and it works, i.e. the binary installs and phpinfo() shows good things. :)
Regards, Michael
|