| Summary: | USE=apache2 emerge -u dev-lang/php => modifies /etc/conf.d/apache2 directly | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tero Pelander <tpeland> |
| Component: | New packages | Assignee: | PHP Bugs <php-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ahipp0, armin76, bug, kjackie, notordoktor, piotrekrogowski, privat, sokann, vostorga |
| Priority: | Highest | ||
| Version: | 10.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Tero Pelander
2010-01-07 07:55:11 UTC
Happy 300000th bug! :D Gentoo has grown pretty well :)(In reply to comment #1) > Happy 300000th bug! :D > Gentoo has grown pretty well :) Uhm, this is by design - you can't have two packages installing the same file overwriting each other on upgrade/re-emerge. /etc/conf.d/apache2 belongs to www-servers/apache, not to dev-lang/php. And it's a bad idea security-wise as well - if you don't enable php in apache, you'll get the PHP files served by Apache as plaintext, possibly including stuff which contains sensitive information. And users will start filing bugs such as Bug 127645 because we've broken PHP by default. (In reply to comment #3) > Uhm, this is by design - you can't have two packages installing the same file > overwriting each other on upgrade/re-emerge. /etc/conf.d/apache2 belongs to > www-servers/apache, not to dev-lang/php. > > And it's a bad idea security-wise as well - if you don't enable php in apache, > you'll get the PHP files served by Apache as plaintext, possibly including > stuff which contains sensitive information. And users will start filing bugs > such as Bug 127645 because we've broken PHP by default. > Anyway this is a bad design. Say I have /etc/conf.d/apache2 like APACHE2_OPTS="-D QQQ -D QAZ" APACHE2_OPTS="${APACHE2_OPTS} -D ZZZ -D ZAQ" Then this got changed to APACHE2_OPTS="-D QQQ -D QAZ -D ZZZ -D ZAQ -D PHP5" APACHE2_OPTS="-D QQQ -D QAZ -D ZZZ -D ZAQ -D PHP5" While this is really not what I want. If you are concerned about security: just ebeep for 10 seconds and print red hot warning. (In reply to comment #4) > If you are concerned about security: just ebeep for 10 seconds and print red > hot warning. Summary - you can't satisfy everyone. See the bug I linked, don't really understand what exactly are you expecting here. People want working stuff out of the box, don't read warnings, don't care about ebeeps and don't want to manually enable every single PHP extension or apache module. If you install mod_php, then you presumably want to use it, otherwise there's no point in installing it. (In reply to comment #5) > (In reply to comment #4) > > If you are concerned about security: just ebeep for 10 seconds and print red > > hot warning. > > Summary - you can't satisfy everyone. See the bug I linked, don't really > understand what exactly are you expecting here. People want working stuff out > of the box, don't read warnings, don't care about ebeeps and don't want to > manually enable every single PHP extension or apache module. If you install > mod_php, then you presumably want to use it, otherwise there's no point in > installing it. Well, I've saw that bug. I agree, that there are a lot of options to install and configure apache with modules, and now understand the decision chosen. So let's modify it slightly to fit some more use cases. I propose to change /usr/share/php-select/libapache.sh from app-admin/php-toolkit to either: 1) backup original /etc/conf.d/apache2 to something like /etc/conf.d/apache2.orig 2) modify /etc/conf.d/apache in-place, but save original "APACHE2_OPTS=.*" as a commented line: "# APACHE2_OPTS=.* # before dev-lang/php" 3) add the following line to the buttom: APACHE2_OPTS="${APACHE2_OPTS} -D PHP5" Also I propose /usr/share/php-select/libapache.sh to ignore commented lines Bug 127645 was based on this use case: "Down the road, apache is upgraded and during etc-update, /etc/conf.d/apache2 is accidently reverted to stock (no extra modules enabled). What happens now Apache is restarted, and mod_php is not loaded. The site now proceeds to serve up .php source code directly. And in the case of MediaWiki, the database passwords are available to all (the bad design of mediawiki is besides the point)." This is clearly a user error, and I see no reason why Gentoo should support this use case. dev-lang/php shouldn't touch files belong to www-servers/apache @Doktor Notor, Of course we can't satisfy everyone. The key here is whether we want to satisfy the Gentoo crowd or the Ubuntu crowd. If you want to satisfy the later, you might as well trigger a /etc/init.d/apache2 restart after emerging php (that's what Ubuntu really does). I providing php by fcgi and suexec and -D PHP5 broking my web serwer... -D FCGI + -D PHP5 doesn't work, and administrator using etc-update don't see changes in /etc/conf.d/apache and searching problem in another files.. I spent 3days before I checked file that shouldn't be modified.. this information is not included in portage info after merge.. its should be providing by etc-update.. or this file couldn't be modyfied after reinstall or upgrade sorry for my poor english ;-) While adding -D PH5 automatically may be seen as a measure of protecting users, it is not really the Gentoo way. Once we move away from php-toolkit, this behaviour will cease and you will have to manually have to add -D PHP to /etc/conf.d/apache2. *** Bug 342063 has been marked as a duplicate of this bug. *** Fixed now. No more php-toolkit |
