# Apache updated - php broken...

## epig

So I do an emerge -upD world on my test-box today (the one with ACCEPT_KEYWORDS="~x86" in make.conf) and find that /etc/apache2/conf/apache2.conf has been replaced by /etc/apache2/httpd.conf

I edit that to my specs, and restart apache, but now it abslolutely refuses to recognize php..... 

I have tried to re-emerge php, gone through all the files, made sure that everything is correct. I the only  file I made changes to was /etc/apache2/httpd.conf

Am I the ony one with this problem? Wouldn't be the first time, but I tought I would check...

A telnet localhost 80 gives the following output:

```
Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

^[

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>501 Method Not Implemented</title>

</head><body>

<h1>Method Not Implemented</h1>

<p>o /index.html not supported.<br />

</p>

<hr>

<address>Apache/2.0.52 (Gentoo/Linux) mod_ssl/2.0.52 OpenSSL/0.9.7e Server at foo.bar.com Port 80</address>

</body></html>

Connection closed by foreign host.
```

Any suggestions?

EDIT: Submitted as Gentoo Bug 83543 https://bugs.gentoo.org/show_bug.cgi?id=83543 Last edited by epig on Mon Feb 28, 2005 12:59 pm; edited 2 times in total

----------

## MoonWalker

This is because mod_php ebuild needs to be updated to work with the new apache herd refresh. I think there should have been a big fat warning about this as anyone emerging and restarting apache now will have a no working php! until php ebuilds been updated.

I just emerged apache and was lucky to figure out this before I restarted, so right now I simply can't restart apache or I loose php and the functionallity of my sites. 

I think this need to be made sticky or there will soon be a flood of crying about none working php!

As affected by it I think you also should file a bug to put it to the php maintainers attention, although I really hope there have been some kind of communication between them and the apache herd and imho this should not have been unmasked until php was done as well as almost everybodu depends on its fuctionality.

----------

## franky999

Yes. I agree. I had the same problem. I was just about searching to fix it.

Does this apply?

----------

## Ries

Joining the club of broken apache owners  :Smile: 

The configuration file also changed from /etc/apache2/conf/* to /etc/apache2/*.  (and apache2.conf -> httpd.conf)

Apache2 location changed (i think)? so all apache stuff is broken (subversion webdav, mod_python, ...) ? i get a "module".so not found after reemerge og php, mod_php, subversion, mod_python.

----------

## MoonWalker

 *epig wrote:*   

> 
> 
> EDIT: Submitted as Gentoo Bug 83543 https://bugs.gentoo.org/show_bug.cgi?id=83543 

 Anything "secret" with this? clicking the link gives me

```
[color=red]  You are not authorized to access bug #83543[/color]
```

----------

## epig

 *MoonWalker wrote:*   

> Anything "secret" with this? clicking the link gives me
> 
> ```
> [color=red]  You are not authorized to access bug #83543[/color]
> ```
> ...

 

Hmmm... Seems that I forgot to uncheck the "Dev relations" box, and now I can't remove it.... 

I will keep you posted?

----------

## MoonWalker

 *Ries wrote:*   

> Joining the club of broken apache owners 
> 
> The configuration file also changed from /etc/apache2/conf/* to /etc/apache2/*.  (and apache2.conf -> httpd.conf)
> 
> Apache2 location changed (i think)? so all apache stuff is broken (subversion webdav, mod_python, ...) ? i get a "module".so not found after reemerge og php, mod_php, subversion, mod_python.

 

I think mod_python is ok, from changelog on yesterdays update

```
 Version bump + uses new apache-module eclass.
```

 and subversion is appearently on its way... but you have to re-emerge those again or they wont pickup apache right.

But the big blocker here is php, as I'm sure at least 70% of all apache installs uses it it's almost amasing this was unmasked before it was compatible! being ~arch ok but still, I'm sure even more of those that run ~arch also runs php  :Confused: 

EDIT: Anyone wanting/needing to keep an eye on the developments of this, see if a module been updated etc. here is the mother of bugs for it https://bugs.gentoo.org/show_bug.cgi?id=76457, check the dependancies of the bug for modules status.

----------

## Ries

 *MoonWalker wrote:*   

>  *Ries wrote:*   Joining the club of broken apache owners 
> 
> The configuration file also changed from /etc/apache2/conf/* to /etc/apache2/*.  (and apache2.conf -> httpd.conf)
> 
> Apache2 location changed (i think)? so all apache stuff is broken (subversion webdav, mod_python, ...) ? i get a "module".so not found after reemerge og php, mod_php, subversion, mod_python. 
> ...

 

Tried to go back to 2.0.52 by emerge =ww...apache-2.0.52, but subversion wants to upgrade it. so i wanted to go back to the -r3. Did a emerge -sync, emerge unmerge apache php mod_php ... and then emerge apache.

But now i get a compile (configure) error

Configuring Apache Portable Runtime library ...

checking for APR... configure: error: the --with-apr parameter is incorrect. It must specify an install prefix, a

build directory, or an apr-config file.

!!! ERROR: net-www/apache-2.0.52-r3 failed.

The error keeps comming... tried to clear ccache and wiped /var/tmp/portage/*

----------

## HomeDawg

I'm among these people with a broken apache also, how soon do you think this issue will be resolved? I run a comercial server on gentoo and I need a resolution for this fast, Thanx for your help.

----------

## Ries

Fixed my apache-2.0.52-r3 not building any more problem..

```
emerge apr apr-util
```

----------

## hairyfeet

FYI bug 83543 is public now.

----------

## j-m

Please read this document before  upgrading Apache to unstable. Do it now or suffer later...  :Exclamation: 

----------

## Ian

While I understand the implications, and don't even really need PHP support anytime soon, does anyone have a relative timeframe of when mod_php will be rewritten?  In any case, looks like I picked a good time to completely redo my installation of Gentoo, so my configuration files were all bare anyways.

----------

## Ladius

Yeah gotta agree, when I noticed the "warning" I had incorrectly assumed the apache herd had actually bothered to make sure some of the important modules "work" or at least still functioned regardless of the upgrade. 

Don't get me wrong I realize I'm not paying anything for this distro and well support is up to those willing to do the support. I just wish they had actually gotten everybody on board before releasing to unstable since clearly this and other mod_something's not working is a rather serious bug that doesn't need further testing to actually catch.

This version of apache gets hard masked in my /etc/portage for the moment

----------

## gentoo_lan

That new unstable apache version should be hard masked until they get php working with it.

----------

## j-m

OK, you all are saying how important you webservers are, so don´t upgrade you production servers to unstable software versions - even without doing the prior required reading. 

 *Quote:*   

> 
> 
> Warning: There are some modules and packages that depend on Apache that have not yet been updated. Please check the dependencies of bug 76457 to see if a critical package for you is still needing to be updated. Neither mod_php nor subversion have been updated yet, and there are several others. If this is the case, then you should wait before updating.
> 
> 

 

 :Rolling Eyes: 

----------

## Ladius

Fortunately I didn't upgrade more than my laptop which exists as my test bed environment. That I was planning on doing php development last night didn't help matters, though the hard masking of apache-2.0.52-r3 and downgrading fixed my problem. 

This forum heck the whole reason for the boards is for community people to interact together and give each other tips and heads up. Specifically when these tips or warnings have not been fully fleshed out by the developers, for after all they aren't perfect nor should they be expected to be. That doesn't stop us the normal users from chipping in when we can.

Again I'm not complainiing that this event happened more how it happened. Clearly reading through the bugs related to mod_php (#77556 specifically)  it shows that this release caught at least a few people unprepared but the apache herd decided to go ahead with the unmasking even though at least the php herd wasn't prepared to implement the new strategy.

----------

## feadin

Here's a quick temporary fix to this problem:

```
sed -e 's/extramodules/modules/g' /etc/apache2/conf/modules.d/70_mod_php5.conf > /etc/apache2/modules.d/70_mod_php5.conf
```

Then restart apache and try again...

I believe I'm not forgetting anything, but I'm soooo tired that I can't be sure right now, so please tell me if it works  :Wink: 

----------

## Ries

 *MoonWalker wrote:*   

> 
> 
> I think mod_python is ok, from changelog on yesterdays update
> 
> ```
> ...

 

I got that working  :Smile:  had to remove the hardmask on mod_python-3.1.4.

----------

## albrow

One other thing...  :Smile: 

For some reason, after doing the fix above, Apache was returning null files no matter what I tried to access.  In /var/log/apache2/error_log I found many lines like the following:

```
[Wed Mar 02 12:51:43 2005] [notice] child pid 31844 exit signal Segmentation fault (11)

```

After hunting high and low, I found an invalid symlink in /etc/php/apache2-php5 called lib.  It's pointing to a directory called extramodules which has been removed in the latest version of Apache.  Change it so that it points to /usr/lib/apache2/modules, restart Apache and ... drumroll please ... it WORKS!

So, if anyone fancies creating an ebuild with the two fixes in...  :Wink: 

----------

## Ries

Actually if you count the people with important webservers, you get "all == 1"  :Smile: 

 *j-m wrote:*   

> OK, you all are saying how important you webservers are, so don´t upgrade you production servers to unstable software versions - even without doing the prior required reading. 
> 
>  *Quote:*   
> 
> Warning: There are some modules and packages that depend on Apache that have not yet been updated. Please check the dependencies of bug 76457 to see if a critical package for you is still needing to be updated. Neither mod_php nor subversion have been updated yet, and there are several others. If this is the case, then you should wait before updating.
> ...

 

----------

## mye

works not  :Sad:  or should I say not really...

I've done the fixes above with php4 and -- the module loads! If I enter http://localhost/bogusurl apache

says ssl and php are loaded  :Razz: 

But damn, my browser keeps downloading any files ending .php

AddType application x-httpd-php .php does not help  :Confused: 

No idea what I got to change to make this work, can't be too difficult hm? (Im not exactly an apache-freak)

----------

## albrow

 *mye wrote:*   

> works not  or should I say not really...
> 
> I've done the fixes above with php4 and -- the module loads! If I enter http://localhost/bogusurl apache
> 
> says ssl and php are loaded 
> ...

 

Mye - can you access non-PHP files OK?

----------

## mye

Non PHP files work, get displayed, render all fine.

Now, just referenced some info.php file -- uh! works!

So PHP IS working but, strange enough, some index.php do NOT work.

Firefox wants to save them with mime-type "phtml" -- but referenced directly

they too work.

localhost/test/ -- saves some type of phtml file with a funny name ( :Confused:   like 4ee325)

localhost/test/index.php -- works fine

and my directoryindex of course knows index.php

----------

## perseguidor

Here's the bugzilla for the overwriting of /var/www/localhost/htdocs/index.html that is on by default after this refresh:

https://bugs.gentoo.org/show_bug.cgi?id=83575

----------

## Ries

 *mye wrote:*   

> Non PHP files work, get displayed, render all fine.
> 
> Now, just referenced some info.php file -- uh! works!
> 
> So PHP IS working but, strange enough, some index.php do NOT work.
> ...

 

I tried to emerge the hardmasked php5. Looks like it places the config and module files at the correct locations. But i have the same problem as you, if i add index.php to DirectoryIndex, it works for indirect index.php files (typing localhost/test/).

DirectoryIndex index.php index.html index.html.var

----------

## Ries

Huhuu, my php is running again.

emerged the hardmasked php version, added index.php to DirectoryIndex and commented out :

TypesConfig /etc/mime.types 

->

#TypesConfig /etc/mime.types 

in httpd.conf  :Smile: 

EDIT: sorry, did'nt work after i restarted apache with stop/start :-\ if it worked at all, maybe i just saw what i so hard wanted  :Smile: 

----------

## lorgoth

I don't usually come here to complain, but I am very disappointed by a number of things in this apache update.  I think that there are a couple of things that were not handled well.  I run Gentoo and ~arch because I like to be able to have the latest versions of software (I build a few apps from CVS and need the latest and greatest of other packages for them to work.  Yes, I could grab those from ~arch and have the majority of my stuff come from arch, but that is more pain that it is worth).  I like to keep my server up to date so I sync up every day and look to see which packages are going to be updated.  Unless it looks like there is a major update of an important package I just start the job and walk away (who watches the messages at the beginning or end of every ebuild to see if they say anything important?).  I noted that apache was going to be updated along with gentoo-webroot.  It didn't look like anything major (it was just a revision...not a new version), so I went ahead.  It blew away my basic homepage and now I don't have working PHP.  It isn't a production machine so this isn't a big deal from a functionality standpoint, but it seems a bit unreasonable.  

I am sure that there are plenty users out there who just stuff a basic index.html file in webroot.  This should not be overwritten.  I understand it shouldn't be there, but how about we upgrade with reality in mind instead of the perfect world in mind.  In the perfect world nobody has their index.html in webroot.  In practice they do.  Please don't overwrite it blindly.  From the bug it looks like this won't change and that seems like a big mistake.  Can someone explain to me why overwriting all files in webroot is a good idea or even acceptable?  

PHP is a very popular apache module.  Why does an apache package get pushed to ~arch w/out a functioning PHP?  Does anyone have an answer?  That seems a bit silly to me.  I guess I don't have any real answers and I do expect little problems like this from time to time running ~arch, but this set of problems seems a bit needless.

----------

## bone

 *lorgoth wrote:*   

> I don't usually come here to complain, but ...
> 
> PHP is a very popular apache module.  Why does an apache package get pushed to ~arch w/out a functioning PHP?  Does anyone have an answer?  That seems a bit silly to me.  I guess I don't have any real answers and I do expect little problems like this from time to time running ~arch, but this set of problems seems a bit needless.

 

I think you answered your own question man. This is ~arch, and exactly that. It's the unstable tree for lack of a better term. Are you actually expecting the unstable tree to work 100%? if so, I think your aiming a little too high.

jt

----------

## j-kidd

From the developer handbook:

 *Quote:*   

> The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable.

 

So, the developer think that the ebuild is stable enough for testing, despite the fact that it will wipe out your index.html and has no support for PHP.

----------

## Ian

 *j-kidd wrote:*   

> From the developer handbook:
> 
>  *Quote:*   The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable. 
> 
> So, the developer think that the ebuild is stable enough for testing, despite the fact that it will wipe out your index.html and has no support for PHP.

 

I'm going to go with someone didn't fully think something out, or just forgot to tell someone else what was going on.  ~Arch does exist for this reason, partially, because shit does happen.  Better it happen in ~Arch than Arch.

Yes, I can understand why someone would be pissed, but give the developers a break guys, they're human...I think.

One thing you can complain about perhaps is that mod_php hasn't been upgraded yet, because that should have been a simple revision, but oh well, I'm not running anything mission critical, so I don't mind not having PHP for a few days.

----------

## lorgoth

 *Quote:*   

> 
> 
> I think you answered your own question man. This is ~arch, and exactly that. It's the unstable tree for lack of a better term. Are you actually expecting the unstable tree to work 100%? if so, I think your aiming a little too high. 
> 
> 

 

If you will read what I said a bit more carefully you will see that I said I expect little problems while running something that is "unstable."  However, this doesn't seem like a problem to me.  It seems like a decision by the developer(s) to push out an ebuild that unexpectedly deletes files and doesn't have common features of the previous version (ie no PHP).  Doesn't that seem a bit more than unstable?  It seems a bit more like broken to me.  I might expect a new package to maybe not compile or to make me reconfigure stuff in a way that isn't polished, but deleting files and removing features is just not acceptable even for unstable in my mind.  Just my 2 cents though.

----------

## MoonWalker

What is ~arch worth for testing if there is nothing to test! It's really a pitty that all the good work the apache herd have done falls behind the spotlight because of a few major mistakes, and I think the biggest of them all is that they don't want to admit it. Reading the diifferent bugs related to this "refresh" clearly show they have caused a tention in the relations with other herds by being so eager to push out their own work. Which probably causes further delays for the updated php to be out...

Also I must say, I don't understand why they wanted this out as a 2.0.52-r3 revision when 2.0.53 has been released by the apache group!

----------

## j-m

Don´t run unstable or suffer. If you are running unstable, then read the related docs first and then update. FYI it is clearly written there that you should not upgrade yet if you need PHP.

----------

## MoonWalker

 *j-m wrote:*   

> Don´t run unstable or suffer. If you are running unstable, then read the related docs first and then update. FYI it is clearly written there that you should not upgrade yet if you need PHP.

 

I run unstable and I don't suffer and I have read the document and therefore I still have a working apache/php. But it doesn't in any way mean one can't discuss how this matter have been handled and have an opinion about it. 

It appears to me with your rhetoric anyone can just trow anything into ~arch and use it as an excuse to hide behind, walking away from any kind of responsability! There are several things pointed out here which I think would be good if the apache herd acknowledged and maybe learned from the mistakes that obviously has been made. This document were the culpits were written wasn't that easy to find as well. If this had been properly annonced at the first place a lot of grief could have been saved, now it slipped though as a "minor" revision change and it's just a question of using common sense that several would miss the fatal effects of it.

EDIT: BTW, a warning in the Change log , at least, would have been proper but nothing! I always check the change log before upgrading 'because' I run ~arch and I expect to find a reference to a bug there or a warning, if it's something serious. This was as an example the case when the paths for apache changed last time to /var/localhost just to mention. But here was nothing, nothing.... that pointed at the major effects of this 'refresh'.

----------

## albrow

 *j-m wrote:*   

> Don´t run unstable or suffer. If you are running unstable, then read the related docs first and then update. FYI it is clearly written there that you should not upgrade yet if you need PHP.

 

IMHO, this is an issue that shouldn't have even been allowed in unstable.  Forgive me if I'm wrong, but unstable should be for unstable apps, not ebuilds.  And if you're doing an emerge -up world, you're not going to know that there even might be a document relating to this until after you've updated and Apache has fallen over.

 *MoonWalker wrote:*   

> It appears to me with your rhetoric anyone can just trow anything into ~arch and use it as an excuse to hide behind, walking away from any kind of responsability!

 

I agree.  As you say, this was hardly a minor revision to an ebuild, but more of a massive overhaul of the way Apache is installed in Gentoo.  Some more shouting should definitely have been done before releasing this ebuild, even into ~arch.  At the very least a block could have been put in the portage tree to ensure that <mod_php-5.0.3 could not be installed at the same time as apache-2.0.52-r3.

----------

## j-m

 *MoonWalker wrote:*   

> This document were the culpits were written wasn't that easy to find as well. I this had been properly annonced at the first place a lot of grief could have been saved, now it slipped though as a "minor" revision change and it's just a question of using common sense that several would miss the fatal effects of it.

 

Would this qualify as a proper announcement?

Otherwise, you should complain about PHP devs, not Apache. Apache is working, PHP team failed to provide updated ebuild. So go to bugzilla and share your opinion in relevant PHP bugs.  :Idea: 

----------

## MoonWalker

 *j-m wrote:*   

> 
> 
> Would this qualify as a proper announcement?

 

Gosh no! This was done on Christmas evening last year, over 2 months ago! Come on, do you even remeber all the chrismas gifts you got? 

If this announcement had been bumped when it actually took place, then it would have been ok. Actually that's all that had been needed.

 *j-m wrote:*   

> Otherwise, you should complain about PHP devs, not Apache. Apache is working, PHP team failed to provide updated ebuild. So go to bugzilla and share your opinion in relevant PHP bugs. 

 

Well I been there and readed all, and it's clear that PHP asked for more time to get ready and had opinions about things as well, but apache wasn't interesting in listening.... nor are they when it comes to overwriting the index.html in webroot! To mee it all comes out as they just want to show off their great work, and doesn't care so much about others. And it's a pitty as they really have done some great work, but their attitude to it kinda blews the value of it!

----------

## j-m

 *MoonWalker wrote:*   

>  *j-m wrote:*   
> 
> Would this qualify as a proper announcement? 
> 
> Gosh no! This was done on Christmas evening last year, over 2 months ago! Come on, do you even remeber all the chrismas gifts you got? 
> ...

 

Yes, exactly. It was put there over two months ago and stayed on the first page for maybe one month. I don´t see what is the point of your complaint? You have been warned at least one month in advance! Or you´d want the announcement to be published after the new ebuilds were unmasked? Huh?  :Rolling Eyes: 

And no - actually almost noone from PHP team had their points - they even did not care to adapt the ebuild to new eclass at all. Throw it on their heads, they are the right target, not Apache.

----------

## lorgoth

 *Quote:*   

> 
> 
> And no - actually almost noone from PHP team had their points - they even did not care to adapt the ebuild to new eclass at all. Throw it on their heads, they are the right target, not Apache.
> 
> 

 

So are you saying that the apache maintainers and the PHP maintainers can't even coordinate their work on a major change to the apache infrastructure?  Wow, that doesn't seem like a very good thing at all.  I would hope that the different dev groups could at least come to some agreement on how to proceed with major changes like this...

----------

## j-m

Unless you have some other problem with getting your Apache work, I am ending this debate. Go and rant in bugzilla.

----------

## glowinthedark

What about setting the APACHE2_OPTS="-D SSL -D PHP5" in /etc/conf.d/apache2

----------

## albrow

 *glowinthedark wrote:*   

> What about setting the APACHE2_OPTS="-D SSL -D PHP5" in /etc/conf.d/apache2

 

Yes, but there's a wee bit more to it than that.

Still running perfectly here (after the fixes mentioned above).

----------

## chacho69

 *feadin wrote:*   

> Here's a quick temporary fix to this problem:
> 
> ```
> sed -e 's/extramodules/modules/g' /etc/apache2/conf/modules.d/70_mod_php5.conf > /etc/apache2/modules.d/70_mod_php5.conf
> ```
> ...

 

This little tidbit of code worked for me  :Smile: 

----------

## j-kidd

 *j-m wrote:*   

> Would this qualify as a proper announcement?

 

Now that you mentioned it, I recall that I have read this announcement before. Firstly, it says nothing about the new webroot. But the most important thing is that I have totally forgot about the announcement since a long time ago. It was just bad communication by putting out the announcement so early without further reminder (e.g. a sticky thread 2 or 3 days before package.mask, another sticky thread 2 or 3 days before ~arch).

 *j-m wrote:*   

> Unless you have some other problem with getting your Apache work, I am ending this debate. Go and rant in bugzilla.

 

Exactly. This thread will stop being a debate if you can just keep yourself out of it.

----------

## Ries

Hell, with all those changes, somebody will anyway end up as roadkill  :Mr. Green:  Some have to be guinea pigs for the greater good.

----------

## echu

Just wanted to chime in,

Firstly, thank you guys for maintaining the packages and seeking the best ways to do things and getting bugs resolved.  Your efforts are much appreciated.

Secondly... this is bush-league package management, and very poor judgement.  I've been using gentoo for quite a while now, but the way this kind of change has been handled leaves a very bad taste in the mouth.  You guys may blame the PHP maintainers, but why stay with a distribution that can't handle their inter-distro package management in a mature manner?  The people who suffer the most are the users.  But who cares about the users anyway?  You put the burden on the users to check the docs or forums for every package that gets updated?  That's totally crazy-talk.  It's not that big of a deal to keep apache masked until things are worked out behind the scenes.  anyway, whatever...  wish drobbins was still around to keep some of these myopic-interests from hurting the entire distribution.

----------

## gentoo_lan

 *echu wrote:*   

> Just wanted to chime in,
> 
> Firstly, thank you guys for maintaining the packages and seeking the best ways to do things and getting bugs resolved.  Your efforts are much appreciated.
> 
> Secondly... this is bush-league package management, and very poor judgement.  I've been using gentoo for quite a while now, but the way this kind of change has been handled leaves a very bad taste in the mouth.  You guys may blame the PHP maintainers, but why stay with a distribution that can't handle their inter-distro package management in a mature manner?  The people who suffer the most are the users.  But who cares about the users anyway?  You put the burden on the users to check the docs or forums for every package that gets updated?  That's totally crazy-talk.  It's not that big of a deal to keep apache masked until things are worked out behind the scenes.  anyway, whatever...  wish drobbins was still around to keep some of these myopic-interests from hurting the entire distribution.

 

First of all we are talking about the testing branch of apache anyway. The packages are masked. They shouldn't be used in a production environment and anyone who has any common sense at all would make sure they understand an upgrade before they make it. Most users should also be intelligent enough to read the warnings that accompany the upgrade and deal with them accordingly. This is hardly bad package management. Bad package management would be to throw the thing up right now and not tell a damn person what to do with it. There is clear documentation on how to manage the upgrade but since it is currently in testing most people shouldn't have to worry about unless of course they are running unstable...and then of course they should know what they are doing in the first place. And if they don't here is a suggestion...run the stable branch and save yourselves the problem.

----------

## younker

worked for me with the masked mod_php package, and after emerge the masked package, you need to remove /etc/apache2/conf directory.

----------

## echu

gentoo_lan,

You may be right about running stable.  I've been running ~arch for several years (since 2002) with just the occasional problem.  So my expectation for ~arch is based upon the standards that have been set previously.  

Like the other guy who posted, I am one who rarely complains.  Take it for what you want, but the fact is that there are people who are unhappy with what happened, and these same people are not the type to usually complain.  I totally believe in a user taking responsibility for their system, but this I would think, does not fall into the realm of what the user should be responsible for.  In this case, I feel that to be personally responsible is to voice my concerns about the way the change was handled.  

If you're the package maintainer, thank you for the hard work you've put into it.  The time that you get the most feedback is when people feel the need to criticize so that kind of sucks for a volunteer effort... It could be discouraging.  Take it for what you want, either everyone who's spoken out in this thread and in bugzilla lack "common sense" and "intelligence" as you say, or maybe there is something that you can take away from this experience besides "people are stupid and its all their fault."

Even if it is user stupidity, it still would benefit the distribution to take these sort of things into account when making changes, and coordinating with the other packages, or at the very least a big one like php.

----------

## Avian

I agree that its simply unacceptable to un-hardmask something that will quite simply destroy an existing working webserver.  The only current way to get PHP5 is to run ~, granted you don't need to run ~ on everything, but i've been doing that for years without a problem until the the day apache got updated.

----------

## cdunham

This is bullshit. And frankly, it's the kind of thing that makes it tough to advocate for using a volunteer-run distribution like Gentoo in *any* serious production environment.

And by the way, the issue isn't masked or unmasked. The fact is, that these are fairly significant changes, some of which will be ironed out by the time the packages are unmasked, some of which will not. You think there is noise about this now, just wait.

But even this isn't the big issue. The big issue is that the Apache and PHP Herds don't seem to have their shit together enough to put their egos aside and work together like adults. That's not going to be solved by masking, announcements, or anything else.

I've been a Gentoo fan and advocate for a few years now, but things are really starting to go downhill here...

----------

## gentoo_lan

Part of the reason the package is probably in testing is there is a significant security risk within apache 2.0.52. Upgrading will make your server more secure. Also reading the warning that major configuration changes have been made is of critical importance and should not be overlooked. Also let me reiterate, packages in testing should not be used in a production environment.

----------

## cdunham

 *gentoo_lan wrote:*   

> Part of the reason the package is probably in testing is there is a significant security risk within apache 2.0.52. Upgrading will make your server more secure.

 

This is news to me. What security risks are in 2.0.52? What is the fix, using the masked 2.0.53?

----------

## gentoo_lan

Well these are the two security fixes but I was mistaken they have already been applied to the current stable apache.

 *Quote:*   

>   *) SECURITY: CAN-2004-0942 (cve.mitre.org)
> 
>      Fix for memory consumption DoS in handling of MIME folded request
> 
>      headers.  [Joe Orton]
> ...

 

----------

## chronophobic

Can I perhaps deviate the discussion away from finger-pointing and ask you guys for some help... Here goes:

I updated to the unmasked version of apache without knowing in any way that the mod_php module isn't yet working (or at least no stable working version was unmasked). Since I play around a bit too much for a newbie I often break stuff, so my first thought was to check my configs and see if I haven't messed up anything... So I messed around the configs for a full hour before I stumbled into the docs about the new apache release. Half an hour later I realized that I was stuck without php (I'd think that for something this important they'd at least put it in big bold letters on top of the document but anyway...). That was yesterday. 

Today I unmasked the latest available release of mod_php and emerged it. BUT now apache still doesn't work with it -- it asks me which program to use to open the .php files. So I checked the paths in the configs again and it seems quite OK... Since I read that it works for you guys, I guess I must have messed up some of the configs... And I'm sure as hell I don't remember what I edited anymore.

So since I can't seem to find where the problem lies, can anybody tell me what can be causing it? (I guess there aren't more than 2-3 places that I can look to solve this). 

Thanx in advance

----------

## cdunham

Well, this is as far as I've been able to get.

* added >=net-www/apache-2.0.52-r3 to /etc/portage/package.mask

* emerge -av apache

* etc-update

* made sure to set APACHE2_OPTS properly in /etc/conf.d/apache2

However, trying to start gave me:

```
Cannot load /etc/apache2/modules/mod_mem_cache.so into server: /etc/apache2/modules/mod_mem_cache.so: undefined symbol: apr_atomic_dec
```

so I commented that module out, now I get:

```
Invalid command 'SSLEngine', perhaps mis-spelled or defined by a module not included in the server configuration
```

Apparently, apache is built without ssl support, despite having the ssl USE flag set!

I'm going to try re-emerging some other stuff, but at this point I'm dead in the water. Fortunately, this is just a test system, but I can see we are going to have to block out several hours of time this week to defend ourselves from this change.

----------

## Rüpel

 *chronophobic wrote:*   

> Half an hour later I realized that I was stuck without php (I'd think that for something this important they'd at least put it in big bold letters on top of the document but anyway...)

 

exactly. fortunately, i read all documentation entirely before emerging anything on my server and since it is a production system, it's running stable x86 only.

but generally: who is using apache without php? i mean, really? to me it doesn't make any sense to change the status of apache (masked, unmasked, unstable, whatever) if there's no accompanying php available yet.

it's the same story as in the beginning of apache2 - as long as there was no php, apache2 was useless for the majority of systems. that's just the way it is.

just my 2 cents.  :Rolling Eyes: 

----------

## gentoo_lan

 *Rüpel wrote:*   

>  *chronophobic wrote:*   Half an hour later I realized that I was stuck without php (I'd think that for something this important they'd at least put it in big bold letters on top of the document but anyway...) 
> 
> exactly. fortunately, i read all documentation entirely before emerging anything on my server and since it is a production system, it's running stable x86 only.
> 
> but generally: who is using apache without php? i mean, really? to me it doesn't make any sense to change the status of apache (masked, unmasked, unstable, whatever) if there's no accompanying php available yet.
> ...

 

Run stable and you won't have a broken PHP...don't use ~arch on production systems!!!

----------

## chronophobic

Yes, yes, point taken already... It's our fault for running unstable, FINE! For me it's just an annoyance, nothing more. But it's just like doing emerge -Davu (or something), seeing an upgrade to mplayer from -r2 to -r3, emerging as usual and finding out that since it's ~arch they didn't bother to include .mpg and .avi support... Don't get me wrong, it's not that I don't appreciate the work those guys did... Once I get php working I'll probably be very happy that I updated, but... Apache and php go together for most practical applications that I know of... Even if it's not the apache herd's responsibility to include mod_php or even consider it, perhaps it was just a bad idea to unmask the revision before the other stuff was working with it...

(and yes, I firmly believe that if you're running a commercial system and you use ~arch (which you shouldn't in that case) that you absolutely rely on you must damn well make sure you know all about the installation beforehand). But for the normal user there might have been a proper warning. It looked like a normal software update, I am no freak but I do 3 of those per day and I've never seen such a major mishap... Come on, they put 1 line in the middle of a document saying "oh, and if you need php stay away from this release"... It's a document that I stumbled on DAYS after the upgrade and only because I started looking for a reason for the breakage.

----------

## cdunham

Yes, ~arch is for testing, we tested it, it broke badly. Now, how do we fix it?

One thing that really held me up was the existence of the 'apr' and 'apr-util' packages. I've been tearing my hair out (and re-emerging tons of stuff) trying to get things restored, and it looks like just removing these packages does the trick.

HTH

----------

## Roguelazer

This is not acceptable. At all. I don't give a care whether it's testing or not. A package that breaks ALL compatability should not be put into x86 or ~x86- it should be hardmasked. When a new version of gnome comes out, one that doesn't even break compatability with existing versions, it's hardmasked. But when a new version of apache2 comes out that makes my entire server useless it's just dumped into ~x86? I run an emerge -u world and then all of a sudden I can't use PHP any more? I'm not a production environment, so I do run ~x86. I expect things to break, to not compile. But I don't expect them to break my system and then to have people blaming me for it. Any more screw ups like this and you can say good bye to me. This is not only the most unprofessional thing I've ever seen, it's quite clearly the stupidest. I will not be ever reccommending gentoo again to anybody looking for a server operating system- you people in charge obviously have no idea what you're doing. You complain "you shouldn't be running testing", but you can't blame us for needing to run ~x86. A package this unstable should NOT be in ~x86. I've been here for how many years now? In that entire time, I've always run ~x86 and I've never had a problem as big as this one. I've never had a problem at all, server-wise. That alone should signify that the blame does not lie with the users who are running unstable...

Also, the sed line doesn't do me any good. My system is just totally borked. So's my index.html. And I never got any warnings. I just ran emerge -u world. Any e_error lines were covered up by the next package down the list (do you really think we watch compiles the whole time they're compiling!?!). I never read that announcement on the news page. 

I'm just... disgusted...

----------

## gentoo_lan

 *Roguelazer wrote:*   

> This is not acceptable. At all. I don't give a care whether it's testing or not. A package that breaks ALL compatability should not be put into x86 or ~x86- it should be hardmasked. When a new version of gnome comes out, one that doesn't even break compatability with existing versions, it's hardmasked. But when a new version of apache2 comes out that makes my entire server useless it's just dumped into ~x86? I run an emerge -u world and then all of a sudden I can't use PHP any more? I'm not a production environment, so I do run ~x86. I expect things to break, to not compile. But I don't expect them to break my system and then to have people blaming me for it. Any more screw ups like this and you can say good bye to me. This is not only the most unprofessional thing I've ever seen, it's quite clearly the stupidest. I will not be ever reccommending gentoo again to anybody looking for a server operating system- you people in charge obviously have no idea what you're doing. You complain "you shouldn't be running testing", but you can't blame us for needing to run ~x86. A package this unstable should NOT be in ~x86. I've been here for how many years now? In that entire time, I've always run ~x86 and I've never had a problem as big as this one. I've never had a problem at all, server-wise. That alone should signify that the blame does not lie with the users who are running unstable...
> 
> Also, the sed line doesn't do me any good. My system is just totally borked. So's my index.html. And I never got any warnings. I just ran emerge -u world. Any e_error lines were covered up by the next package down the list (do you really think we watch compiles the whole time they're compiling!?!). I never read that announcement on the news page. 
> 
> I'm just... disgusted...

 

Well from my understanding of the issue it was a miscommunication between the apache and php herd. Maybe instead of griping about it you could pose some potential changes within their structure or management to better resolve these issues within the future.

----------

## Roguelazer

1st change: If it breaks existing installs, put it in package.mask until the php, perl, etc people have had time to fix their ends

2nd change: Don't blame the users. It's bad policy.

3rd change: Don't take a week to put out a fix. A week is a looooong time.

----------

## Ian

A very easy solution.

HAVE THE DIFFERENT DEVELOPMENT GROUPS TALK TO EACH OTHER.

If Apache2 is going to change things to be more like other distros, great, I'm all for it.  But if it's going to break php (or anything else), then no good.  Wait for all related projects to be updated, and then push the ebuilds into ~arch.

Or, better yet, BLOCK the ebuilds from being installed while old versions are still there.  If the newer version of php isn't installed, block the newer version of apache2.  It's trivial for the user to then unmerge the old apache, and emerge the new version with new configuration files.

I got php working on my server again by unhardmasking the latest version, so I've got no problems now, but it's annoying to have to deal with it.  I'd rather be told before hand, hey, this'll break stuff, so do it this way to minimize the pain.

We're also missing a HUGE problem, that the ebuild just wiped out your server dir.  Granted, there's a new USE flag for that, but it should be disabled by default, not enabled by default.  I'll leave that problem to everyone else though, because I got lucky and had nothing in my server dir that got killed.

----------

## JKT7

Can we move the ranting to somewhere else? Back to the problem....

I merged the hardmasked version of mod_php, applied the sed fix mentioned above, and changed the invalid symlink. I'm still getting a browser prompt to download the php file when I try to access a PHP page, as some other people mentioned before the ranting started. Any ideas?

Actually... it works in IE but not in Firefox? Any idea why that might be the case?

----------

## baraquda

Well, the solution for the whole problem is as simple as it could be: 

# mv /etc/apache2/conf/modules.d/70_mod_php5.conf /etc/apache2/modules.d

The php-modules file was simply stored in the wrong directory! Now PHP works again on my machine  :Cool: 

----------

## manzanares

Anyways, I was happily running apache 2.0.49 untill for some STUPID reason I installed 52 without reading the docs.

Now 2.0.52 keeps on giving problems with my email (qmail) delivery; even internally !!

What would be the safest way to reset everything as it was ? i.e. Back to Apache 2.0.49

The commands would be *greatly* appreciated. 

Baraquda: Could your method help and have any influence on my mail delivery ?

Thanks. Manzanares

----------

## Haqqax

Can anybody give some link to a document describing how to stop using unstable packages? I would like to know what it takes to "downgrade" to stable Gentoo.

----------

## gentoo_lan

 *Haqqax wrote:*   

> Can anybody give some link to a document describing how to stop using unstable packages? I would like to know what it takes to "downgrade" to stable Gentoo.

 

 *manzanares wrote:*   

> Anyways, I was happily running apache 2.0.49 untill for some STUPID reason I installed 52 without reading the docs.
> 
> Now 2.0.52 keeps on giving problems with my email (qmail) delivery; even internally !!
> 
> What would be the safest way to reset everything as it was ? i.e. Back to Apache 2.0.49
> ...

 

Read up on the package.mask file.

----------

## hunn

For those of you who did not get the hardmasked mod_php to work, this is what I did:

```
1. unmask dev-php/mod_php-5.0.3-r1

2. emerge mod_php

3. mv /etc/apache2/modules.d/40_mod_ssl.conf /etc/apache2/modules.d/40_mod_ssl.conf-tmp

4. /etc/init.d/apache2 restart

5. Goto http://localhost/index.php
```

Worked  :Smile: 

Don't ask me why, but to me it semmed like mod_ssl stopped the reading of modules.d/*.conf

At least I'm a happy Gentoo user again  :Smile: 

----------

## chronophobic

AAAARGH! And it STILL doesn't work for me! How do you spell FRUSTRATION?

Anyways, how long until this whole thing is fixed the  _right_way?

----------

## echu

A few other things to watch out for.  In the new configuration file (httpd.conf) I noticed the setting for /var/www/localhost/htdocs was "AllowOverride None" which means none of your .htaccess files would work. 

Its probably worth the time to comb over the configurations and make sure everything is similiar to what you had before.

----------

## PeeJay

I've unmerged php, mod_php and apache, re-emerged the stable versions and now I get this error:

Syntax error on line 68 of /etc/apache2/conf/apache2.conf:

Cannot load /usr/lib/apache2/modules/mod_mem_cache.so into server: /usr/lib/apache2/modules/mod_mem_cache.so: undefined symbol: apr_atomic_dec

if I comment out that line apache loads but dosen't seem to respond to requests, ie. web browser dosen't complain but dosen't do anything either.

----------

## echu

Try emerging apr and apr-util.

----------

## KaszeL

 *echu wrote:*   

> Try emerging apr and apr-util.

 

For me unmerging apr, apr-utils and then reemerging apache does the trick.

----------

## franky999

I just emerged the latest mod_php and everything is working fine here. I just had to change my DirectoryIndex in httpd.conf so it would also take php files as the index file. Using ~arch.

----------

## chronophobic

I re-emerged all the relevant stuff, went through all the config as suggested, verified that the files are in place where they should be (no old config files either), restarted apache a bunch of times and I'm STILL getting the same error -- browser is trying to download the php files. 

The problem that I see is that for some reason the php module is sitll not loaded, since the Apache server message says "apache so-and-so, ssl so-and-so" but never mentions php (which it normally should if the module is loaded). 

I tried just renaming the index.php to index.html and it still tries to download it (in the php5 module config settings it does NOT say to parse html files for php, and in httpd.conf it recognizes both as directory indexes). However the server displays correctly the banner html in the root directory, so I guess it's working properly for non-php stuff...

Any suggestions? Does anybody know why the php module would still refuse to load (or how I can check if it does or what the errors are?)

EDIT: err... you might as well not reply, it's sorta working now... I've gotta go to an exam in 5 minutes and then I'll try to sort it out again...

----------

## Roguelazer

Are you sure that /etc/conf.d/apache2 has the right options? Here's the relevant line from my file:

```
APACHE2_OPTS="-D SSL -D PHP5 -D DAV -D DAV_FS"
```

----------

## chronophobic

Of course, I checked over all the settings about 10 times... Tried with SSL, tried without, tried messing with php, tried re-emergint it. Now it works but don't ask me why. I won't touch anything and I'm a happy man. As they say "as long as it's running, don't fix it".

Btw, what's the difference between starting apache by typing "apache2" or by "/etc/init.d/apache2 start"? Cuz only the first way works for me right now, the second way doesn't seem to be checking the configs.

----------

## madbiker

What a headache.

I've tried downgrading to 2.0.49, playing with apr and apr-util thing to get it compile and start fine, but no php there. Then I saw all these success stories with the new versions of mod_php and apache. So I get rid of the masks and upgrade again. Using the latest apache, mod_php and php builds, still no luck. I tried adding another 

```
LoadModule php5_module modules/libphp5.so
```

 line to my httpd.conf. Then I get a message on startup about the module already being loaded.

I noticed my /etc/conf.d/apache2 had APACHE_OPTS="-D SSL -D PHP5" set, but the commented out example talked about "APACHE2_OPTS". Tried setting that with the same settings, but still doesn't work.

I used to have the problem with firefox trying to save php files, but now I'm down it it displaying them as plain html. I've re-emerged mod_php, apache and php with no success. ARGH.

[edit] Re-emerged apache again and it works now.  :Confused: 

----------

## beu

Hi folks,

First of all, apologies to all of you who have been burnt by the issues described in this thread.  Also, thanks too all you who offered help, much appreciated !  :Smile:   We'll have to start watching the forums more closely from now on  :Twisted Evil: 

Anyways, these issues should all be resolved; if your running with >=apache-2.0.52-r3 (or >=apache-1.3.33-r1), then all you need to do is emerge either >=mod_php-4.3.10-r1 (for PHP4 support) or >=mod_php-5.0.3-r1 (for PHP5 support) - both are in ~arch.  Once emerged, the usual adding of "-D PHP4" or "-D PHP5" to your apache's conf.d file and a full apache restart ("/etc/init.d/apache2 stop; /etc/init.d/apache2 start" for Apache 2.x) and you should be all set.

You will also need to add index.php (and possibly others) to the 'DirectoryIndex' directive in your httpd.conf or per-directory .htaccess files if they are not already in your own virtual host configurations (this is only temporary measure and will be fixed very soon).

If you continue to have problems, and a re-emerge of mod_php does not solve it, feel free to drop by #gentoo-apache on irc.freenode.net, and we'll try and help you.  :Very Happy: 

- beu

----------

## hans0r

well, i tried all the tips mentioned in this thread how to solve this problem.

phpmyadmin works ok now, but videodb still doesn't.

when i browse to http://localhost/videodb firefox tries to download index.php

----------

## Ashe

And in horror moment, mod_php is hard-masked.

package.mask says...

 *Quote:*   

>  automatically activates ZTS mode when any threaded MPMs are installed,
> 
> # even if mpm_prefork is the default
> 
> =dev-php/mod_php-5*
> ...

 

so the question is, how much a blocker is this? If we don't enable any of the new mpm options when emerging apache, is it going to work like it always has, or are thos eof us using php5 basically out of luck?

----------

## Match

Mm - any ideas when we'll be able to move back to 5? It's a bit frustrating really..

----------

## CrazyPyro

I am running mod_php-5.0.3-r1 and apache-2.0.53 (compiled with all mpm-* USE flags disabled) with no problems.  

I don't know what would happen if you have any of the mpm's enabled though - I wouldn't try that on a production box...

----------

## CrazyPyro

Also, I read Stuart Herbert's comments that I found linked to from another post, which seem to suggest that the newest masked version of mod_php-5.0.3-r2 actually fixes the problems that got php5 maksed in the first place.  Though as I said before, I'm not using MPMs so I can't comment on whether this works or not.  I'm guessing it will be unmasked in a day or two as soon as people verify Stuart's fixes.  I plan on testing this myself later tonight.

----------

## niXers

Just like to mention that I almost had the same exact problem and I fixed it the way I explained here. Check it out. It will fix your PHP problem.  :Razz: 

----------

## CrazyPyro

In response to my previous post, I recompiled apache-2.0.53 with the following USE flags: 

```
+apache2 -debug -doc +ldap +mpm-leader -mpm-peruser +mpm-prefork +mpm-threadpool +mpm-worker -no-suexec +ssl -static-modules +threads
```

 I then emerged mod_php-5.0.3-r2.  (I had to unmerge mod_php-5.0.3-r1 first though, because apparently r2 wanted to install in a new slot.  Weird.  Can anyone else confirm?)  In short, everything seems to be fine as long as I'm using the default (prefork) MPM.  The multithreaded MPMs disagreed with my mod_perl, and "worker" even crashed my system.  But then, that isn't a mod_php issue.

----------

