From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JHO1W-0000tG-17 for garchives@archives.gentoo.org; Tue, 22 Jan 2008 18:39:02 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13C0EE099D; Tue, 22 Jan 2008 18:39:00 +0000 (UTC) Received: from dozer.foobar.lu (dozer.foobar.lu [80.90.44.130]) by pigeon.gentoo.org (Postfix) with ESMTP id C5DE6E099D for ; Tue, 22 Jan 2008 18:38:59 +0000 (UTC) Received: from localhost ([127.0.0.1]) by dozer.foobar.lu with esmtp (Exim 4.68) (envelope-from ) id 1JHO1Q-00022G-G6 for gentoo-server@lists.gentoo.org; Tue, 22 Jan 2008 19:38:56 +0100 X-DSPAM-Result: Innocent X-DSPAM-Confidence: 0.9992 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4796383b77751804284693 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at foobar.lu Received: from dozer.foobar.lu ([127.0.0.1]) by localhost (dozer.foobar.lu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0X8xvW5BZEl for ; Tue, 22 Jan 2008 19:38:46 +0100 (CET) Received: from phreak.foobar.lu ([80.90.62.47] helo=[192.168.100.100]) by dozer.foobar.lu with esmtpa (Exim 4.68) (envelope-from ) id 1JHO1D-000211-UI for gentoo-server@lists.gentoo.org; Tue, 22 Jan 2008 19:38:44 +0100 Message-ID: <4796382F.1060001@foobar.lu> Date: Tue, 22 Jan 2008 19:38:39 +0100 From: Yves Thommes User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-server@lists.gentoo.org Reply-to: gentoo-server@lists.gentoo.org MIME-Version: 1.0 To: gentoo-server@lists.gentoo.org Subject: Re: [gentoo-server] PHP4 References: <20080118110850.C41241@shell.bway.net> <47961632.5000000@foobar.lu> <479617AD.3040800@gentoo.org> <1201025554.5987.27.camel@localhost.localdomain> In-Reply-To: <1201025554.5987.27.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 69c95076-ac3e-4bc2-837b-59c3b9041d70 X-Archives-Hash: 5c0eddfa96c2b209bb88f20dfa8b9610 hey lindsay, thank you for your feedback. i already was playing around a little bit with php4 and php5 concurrent installations and they worked very well. what we've actually done so far was put all of the websites (about a dozen), which absolutely require php4 to run, on a dedicated box. all other web servers have been running php5 only for several months now. the problem with the deprecated php4 module ebuild would of course only affected this single box. of course migrating a website from php4-only to php5-compatible software is mainly a political decision in my case. i'm rather in a tight spot, management of course doesn't want to drop the customers and either the customer doesn't have the resources to pay for a migration, or maybe even the web-agency who developed the website several years ago has been put out of business or and we don't have the know-how ourselves to migrate the system. so i only saw the situation from a system administrators point of view who only wanted to know of there was a possibility that the php4 ebuild would only be masked or if there was some other solutions (like local portage overlay, just as an example). you wouldn't believe how many customers would rather be ok to be hosted on a server where we could no more guarantee the security for their website because the technology used is no longer supported, than invest into a migration to a newer system. the problem with the missing php4 ebuild is not about "no more php4 security updates", i know that php4 support has been officially dropped, the problem would rather have been with dependencies i guess. and that's why i posted to this mailing list, just to get advice, i suppose that's one of the purposes of a mailing list. thanks for your help, i guess i'll figure something out. Lindsay Haisley wrote: > On Tue, 2008-01-22 at 10:19 -0600, Andrew Gaffney wrote: > >> So...you know enough to run your ISP on Gentoo (at least I'd hope so), but you >> think that the ebuilds being removed from portage will mean you can no longer >> have php4? If you really want to keep it, stick the ebuilds in an overlay and >> stop complaining. >> >> Gentoo is removing the php4 ebuilds from the tree, because it won't be >> security-supported by upstream very shortly. Gentoo doesn't have the manpower to >> do security backports and such....we just bump to the next version. Until you're >> paying to use Gentoo, please don't complain about how the distro does things. >> Especially when the complaint it "stupid". >> > > Andrew, please be moderate in your responses. We're all doing the best > we can with a complex technology. Information and sound analysis help. > Sarcasm and insulting words don't. This is a technical forum. > > Yves, the bottom line here is that PHP4 has been found by the upstream > PHP developers to have security flaws that aren't easily addressed, and > probably won't be. Many distributions, not just Gentoo are dropping > support for it since the upstream development focus has switched to PHP5 > and PHP6. > > Some of your customers may have issues with their scripts and PHP5, but > having done this upgrade as a consultant to a programmer with a major, > very OO PHP-based research software system, my observation is that the > problems are probably relatively minor and easily fixed. Two things to > remember: > > 1. It's important to take a good look at the php.ini files for both > PHP4 and PHP5 and make sure that all the options which might affect > script execution are compatible. > > 2. It's possible (there's a Gentoo HOWTO on it) to run both PHP4 and > PHP5 on the same system and use either one on a per-directory or > per-file basis, so you can switch potentially problem customers over to > PHP5 one by one. > > My guess is that upgrading globally to PHP5 will affect a relatively > small percentage of your customer base if php.ini synchronization is > good. PHP5 is very backward compatible in most things. Your decision > and your actions must also depend on your evaluation of the security > risks, and how the value of your work in maintaining PHP4 and dealing > with possible security breaches balances against the work involved in > upgrading to PHP5 and helping your customers with possible scripting > issues. > > There are a lot of ways to maintain an obsolete package, the simplest of > which is to download the upstream developers' source package and build > and install it outside of Gentoo - not advisable but very doable. > > -- gentoo-server@lists.gentoo.org mailing list