Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] APXS LoadModule Option in configure »

[RFC] APXS LoadModule Option in configure

php.internals

Kris Craig

14 years ago
Opening discussion on RFC pertaining to adding a new option to the configure script with regard to how/whether APXS touches the httpd.conf file. This is my first RFC post so please go easy on me if I screwed-up on procedure in any way. =) Here it is: https://wiki.php.net/rfc/apxs-loadmodule Thanks! --Kris

Unnamed Person

14 years ago
Kris Craig <kris.craig@gmail.com> writes:
> Opening discussion on RFC pertaining to adding a new option to the > configure script with regard to how/whether APXS touches the httpd.conf > file. > > This is my first RFC post so please go easy on me if I screwed-up on > procedure in any way. =) > > > Here it is: https://wiki.php.net/rfc/apxs-loadmodule > > Thanks! > > --Kris
I, for one, would prefer this behavior to be toggalable at the least, and preferably to not touch httpd.conf by default.

Johannes Schlueter

14 years ago
Hi, On Mon, 2012-02-20 at 17:02 -0800, Kris Craig wrote:
> Opening discussion on RFC pertaining to adding a new option to the > configure script with regard to how/whether APXS touches the httpd.conf > file. > > This is my first RFC post so please go easy on me if I screwed-up on > procedure in any way. =) > > > Here it is: https://wiki.php.net/rfc/apxs-loadmodule
A bit history: The svn revision r192467 had this comment: - Changed -a to -A to prevent enabling PHP in httpd.conf automatically. # Most distributions use separate file in a conf.d/ directory to enable # PHP, using -a would add unnecessary line in the main httpd.conf and # causes a warning during startup. This was reverted in r194843 - Revert -a to -A change, bad idea: It disables EXISTING lines too! I think we should be careful there. johannes

Kris Craig

14 years ago
@Johannes Agreed. That was one of the reasons I decided to make the existing behavior (i.e. "-a") the default. I haven't independently confirmed that issue in APXS but I have heard it mentioned before; I'll test it myself when I get home just to make sure, since the APXS docs are a bit vague on this. Either way, I think so long as our documentation is clear and the existing behavior is default then it shouldn't pose a problem. --Kris 2012/2/20 Johannes Schlüter <johannes@schlueters.de>

Kris Craig

14 years ago
Any further thoughts on this? --Kris On Mon, Feb 20, 2012 at 5:36 PM, Kris Craig <kris.craig@gmail.com> wrote:

Richard Lynch

14 years ago
On Mon, February 20, 2012 7:02 pm, Kris Craig wrote:
> Opening discussion on RFC pertaining to adding a new option to the > configure script with regard to how/whether APXS touches the > httpd.conf > file. > > This is my first RFC post so please go easy on me if I screwed-up on > procedure in any way. =) > > > Here it is: https://wiki.php.net/rfc/apxs-loadmodule
This seems to me like a useful addition, with minimal risk, and many sysadmins would welcome it. Has to default to current behavior, of course, which one might want to add to the RFC explicitly. +1 until somebody explains why it's "bad" :-)
-- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

Kris Craig

14 years ago
Thanks for the input! You're right, I'll go ahead and clarify that in the RFC. I'll probably initiate voting on Monday unless something changes between now and then. --Kris On Fri, Feb 24, 2012 at 2:24 PM, Richard Lynch <ceo@l-i-e.com> wrote:

Christopher Jones

14 years ago
On 02/24/2012 02:38 PM, Kris Craig wrote:
> Thanks for the input! You're right, I'll go ahead and clarify that in the > RFC. > > I'll probably initiate voting on Monday unless something changes between > now and then. > > --Kris
Re https://wiki.php.net/rfc/apxs-loadmodule The RFC needs more work before voting. It needs to explain what exact circumstances & versions cause the problem you are trying to solve. I haven't had a clashing LoadModule since PHP 6 was rebranched and became 5.5-dev. To me this means that the feature adds complexity without current value. The open questions about Apache 1.3 don't belong in the RFC. Document your decisions about what is and isn't going to be supported by the enhancement so that voters know exactly what they are voting on. If you proceed with the RFC, consider overloading the current syntax with the standard optional comma separator: –with-apxs2=enabled,/path/to/apxs # or disabled,/path/to/apxs Also, choose a good time to begin voting, e.g. after 5.4 is released. Chris
-- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/

Christopher Jones

14 years ago
On 02/24/2012 02:38 PM, Kris Craig wrote:
> Thanks for the input! You're right, I'll go ahead and clarify that in the > RFC. > > I'll probably initiate voting on Monday unless something changes between > now and then. > > --Kris
The real issue with the PHP install is that it doesn't add "AddType" or "SetHandler" to update httpd.conf. Basic users relying on .php file extensions have to manually edit the file. It would have been friendly to make the default install "just work" for these people. Experienced developers will want to make their own changes regardless of what the base install does. Easier said than done, but that makes it a good project.
-- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/

Kris Craig

14 years ago
Yeah since we pretty much rely on APXS to do the httpd.conf stuff, we're really limited in terms of what we can do. That is, unless we want to start manually doing this in the configure script in lieu of APXS, though I'm not sure that would be worth the trouble and the overhead. LoadModule clashes still happen in the current releases. I haven't tested it on 5.5-dev but it definitely exists on 5.3.x. I have yet to test it on 5.4 but I'm not aware of any changes there that would've affected this. So this is an existing problem, though admittedly it's really just more of an unnecessary annoyance. If you're doing QA work or something else that involves frequent PHP rebuilds and you have your PHP configuration in a separate .conf file (as is good practice anyway), this tends to become quite irritating. And since APXS already has the solution built-in, it seems kinda silly not to make use of it. The open question of course won't be in the RFC when voting begins. However, I have yet to hear from one single person on that question. I'll make an arbitrary decision on that if nobody cares, but I want to give everyone an opportunity to weigh-in on that question. At very least, could somebody tell me if we're still supporting Apache 1.3.x or not? If we are, any idea if/when we're planning on phasing that out? I'd feel a lot better if I at least knew where we stood on that. I'll look into the comma separation suggestion and see if that'll work. Mainly I just want to make sure we're not breaking any existing functionality; i.e. I want people to be able to not specify this at all and still get the same behavior they did before this change. --Kris On Fri, Feb 24, 2012 at 3:34 PM, Christopher Jones < christopher.jones@oracle.com> wrote:

Christopher Jones

14 years ago
On 02/24/2012 03:54 PM, Kris Craig wrote:
> LoadModule clashes still happen in the current releases. I haven't > tested it on 5.5-dev but it definitely exists on 5.3.x. I have yet > to test it on 5.4 but I'm not aware of any changes there that > would've affected this. So this is an existing problem,
It doesn't happen for me and I frequently build PHP 5.3, 5.4 and trunk mods. The library name is the same for all branches. Are you sure it's not a feature/bug of your APXS version? Anyway, the RFC needs more investigative description, IMHO. Chirs
-- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/

Kris Craig

14 years ago
No, it happens and it's even clearly documented in APXS. Basically, if you specify the "-a" option in APXS, it overwrites your httpd.conf (or apache.conf or whatever it is on your system) and adds the LoadModule line to it. In PHP's configure script, you'll notice that "-a" is always specified; there's no option to use APXS without it. As a result, "make install" will always overwrite your LoadModule entry in httpd.conf if APXS is enabled. The problem occurs when you have LoadModule in an included .conf file already; APXS does not have the ability to detect that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf by APXS, and thus the clash occurs. This behavior has been reproduced numerous times. I think the RFC is pretty clear on how this works. Nobody else has expressed confusion thus far. I could clarify further but I'm not sure how; it's pretty straight-forward, really. I'm not sure what may have been happening in your case or if perhaps you misunderstood what this RFC is about. Either way, I would recommend you create a fresh Linux-based build environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away from yum/apt-get), then attempt to generate an APXS-enabled Makefile using PHP's configure script that does not activate APXS with the "-a" option. It might also be a good idea for you to check-out the APXS documentation (I included a link to it on the RFC). Those steps should enable you to reproduce this. =) --Kris On Fri, Feb 24, 2012 at 4:02 PM, Christopher Jones < christopher.jones@oracle.com> wrote:

Christopher Jones

14 years ago
On 02/24/2012 04:14 PM, Kris Craig wrote:
> No, it happens and it's even clearly documented in APXS. > > Basically, if you specify the "-a" option in APXS, it overwrites your > httpd.conf (or apache.conf or whatever it is on your system) and adds the > LoadModule line to it. In PHP's configure script, you'll notice that "-a" > is always specified; there's no option to use APXS without it. As a > result, "make install" will always overwrite your LoadModule entry in > httpd.conf if APXS is enabled. The problem occurs when you have LoadModule > in an included .conf file already; APXS does not have the ability to detect > that. Therefore, a "duplicate" LoadModule entry is added to httpd.conf by > APXS, and thus the clash occurs. This behavior has been reproduced > numerous times.
I can start with a LoadModule line, run the exact apxs command that the PHP Makefile executes and I still have only one LoadModule in the file. Note the time stamp of the file changes. cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/httpd.conf -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30 /home/cjones/apache22/conf/httpd.conf cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/httpd.conf LoadModule php5_module modules/libphp5.so cjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S LIBEXECDIR=/home/cjones/apache22/modules -S SYSCONFDIR=/home/cjones/apache22/conf -i -a -n php5 libphp5.la /home/cjones/apache22/build/instdso.sh SH_LIBTOOL='/home/cjones/apache22/build/libtool' libphp5.la /home/cjones/apache22/modules /home/cjones/apache22/build/libtool --mode=install cp libphp5.la /home/cjones/apache22/modules/ cp .libs/libphp5.so /home/cjones/apache22/modules/libphp5.so cp .libs/libphp5.lai /home/cjones/apache22/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /home/cjones/phpbuild/php53 /libs' chmod 755 /home/cjones/apache22/modules/libphp5.so [activating module `php5' in /home/cjones/apache22/conf/httpd.conf] cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/httpd.conf -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33 /home/cjones/apache22/conf/httpd.conf cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/httpd.conf LoadModule php5_module modules/libphp5.so I could interpolate the "apxs -a" documentation that says "or by enabling it if it already exists" to support what I see. Good luck with your RFC, Chris
-- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/

Kris Craig

14 years ago
Oh ok, I think I see where you're getting confused. This problem occurs when your LoadModule statement is in a *separate* .conf file; i.e. using the "Include" statement. APXS cannot detect this and just sticks a LoadModule into the main .conf file. This is what causes the duplication. It's a very common issue as many people (myself included) prefer to keep their PHP configurations separate. --Kris On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones < christopher.jones@oracle.com> wrote:

Kris Craig

14 years ago
Ok, I've updated the RFC based on input received here. I also made a decision on the APXS vs. APXS2 question; please refer to the RFC for details. If anybody has any objections to this decision, now would be the time to say something! I've targetted this for 5.4.1 so this won't have any bearing on the upcoming 5.4.0 release. If I don't hear any new objections, I plan to initiate the vote sometime early this week. https://wiki.php.net/rfc/apxs-loadmodule --Kris On Fri, Feb 24, 2012 at 4:44 PM, Kris Craig <kris.craig@gmail.com> wrote:

Richard Lynch

14 years ago
On Fri, February 24, 2012 6:14 pm, Kris Craig wrote:
> No, it happens and it's even clearly documented in APXS. > > Basically, if you specify the "-a" option in APXS, it overwrites your > httpd.conf (or apache.conf or whatever it is on your system) and adds > the > LoadModule line to it. In PHP's configure script, you'll notice that > "-a" > is always specified; there's no option to use APXS without it. As a > result, "make install" will always overwrite your LoadModule entry in > httpd.conf if APXS is enabled. The problem occurs when you have > LoadModule > in an included .conf file already; APXS does not have the ability to > detect > that. Therefore, a "duplicate" LoadModule entry is added to > httpd.conf by > APXS, and thus the clash occurs. This behavior has been reproduced > numerous times. > > > I think the RFC is pretty clear on how this works. Nobody else has > expressed confusion thus far. I could clarify further but I'm not > sure > how; it's pretty straight-forward, really. I'm not sure what may have > been > happening in your case or if perhaps you misunderstood what this RFC > is > about. Either way, I would recommend you create a fresh Linux-based > build > environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away > from > yum/apt-get), then attempt to generate an APXS-enabled Makefile using > PHP's > configure script that does not activate APXS with the "-a" option. It > might also be a good idea for you to check-out the APXS documentation > (I > included a link to it on the RFC). > > Those steps should enable you to reproduce this. =)
Once upon a time, a lonnnnnng time ago, I read through the configure / make process, and I *thought* there was logic there to try to detect if your httpd.conf diverged significantly from the default, and, if so, it would choose NOT to add the LoadModule line, assuming you were a power user who had it somewhere else... I could be mis-remembering. This logic could have been removed. I could be hallucinating. The logic I saw could have been doing something entirely difference, as I have only a vague notion of how configure/make works in the first place. It could have been some other project. Or this could account for your different experiences, based on whether you "hacked" httpd.conf "enough" or started with a fresh out of the box one and didn't touch it until after installing PHP. ymmv ianal
-- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE

Kris Craig

14 years ago
@Richard I think, briefly, something like that was implemented. However, it was reverted soon after because it changed the default behavior of configure. This was discovered to be a problem after people realized that, if -a is not specified, APXS will not only skip writing the LoadModule line, but for some inexplicable reason it will also strip the existing LoadModule line if it's already there. I'm guessing that's probably what you're remembering. This RFC differs in that the default behavior of configure will remain unchanged. @Lester Generally, this is a problem that surfaces in manual PHP builds. You're correct in that the packaged repos tend to handle all that stuff for you anyway. However, these repos are rarely updated (I think CentOS and Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP manually if you want to take advantage of the latest features. In these cases, being able to isolate the PHP configuration tends to make the most sense, hence why this new option switch is necessary IMHO. --Kris On Mon, Feb 27, 2012 at 8:59 AM, Richard Lynch <ceo@l-i-e.com> wrote:

Lester Caine

14 years ago
Kris Craig wrote:
> @Lester Generally, this is a problem that surfaces in manual PHP builds. > You're correct in that the packaged repos tend to handle all that stuff for > you anyway. However, these repos are rarely updated (I think CentOS and > Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP > manually if you want to take advantage of the latest features. In these > cases, being able to isolate the PHP configuration tends to make the most > sense, hence why this new option switch is necessary IMHO.
I've obviously been doing something wrong then :) SUSE has been keeping my versions up to date quite happily even to the extent that I now have to make sure I DON'T get an update applied until I've had a chance to check the live sites! But I still have to manually build the more useful extensions that are not included, and it's at this time that the build 'defaults' tends to screw with the SUSE configuration :(
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php

Ferenc Kovacs

14 years ago
> > > @Lester Generally, this is a problem that surfaces in manual PHP builds. > You're correct in that the packaged repos tend to handle all that stuff for > you anyway. However, these repos are rarely updated (I think CentOS and > Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP > manually if you want to take advantage of the latest features. In these > cases, being able to isolate the PHP configuration tends to make the most > sense, hence why this new option switch is necessary IMHO. > >
AFAIR centos 5.7 provides php 5.2.1 (centos 4 has only Maintenance updates, for 2 more days) the oldest ubuntu (8,04 lts) also have 5.2.4 so I think that the only distro with support that ships >=5.2 is rhel 4 with the Extended life cycle. but usually there are semi-official/community repos providing more up-to-date versions for each distribution.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu