theweaselking: (Default)
[personal profile] theweaselking
PHP has zip functionality. It must be enabled at compile-time. This means you need to build PHP from source if you want to use it.

Fine, I can deal with that. I have a lovely fresh-built binary of php with all the options I want.

How the fuck do I tell apache that it should use my nice fresh new binary and not it's old and busted php module? I've tried adding an application handler for files with a php extension and an Action directing it to the fresh new binary. It 404s. This is, in fact, the entirety of the change:
AddHandler php5zip .php5
Action php5zip usr/lib/cgi-bin/php
Where, of course, the new binary is /usr/lib/cgi-bin/php - and yes, it's executable.

And why are there *no* helpful tutorials on this, anywhere on the internet, that I can find?

I don't even really want to use it as CGI. I don't care how I use it. I just want to be able to make Apache use a new version of PHP *in any way* from source that I have built myself. ANY METHOD AT ALL is good, as long as I can make this change, and, in the future, make any other changes I might want to make to php.

(Apache 2, PHP 5.x - I can use any version I want, as long as it's PHP5, Ubuntu 6.06 Server)

(no subject)

Date: 2007-09-07 03:27 pm (UTC)
From: [identity profile] giza.livejournal.com
Stupid question: are you restarting Apache after changing the config file?

Did you grep through any other config files and look for any other references to PHP that might be causing interference? (Yes, I see you're using "php5" and not "php". But who knows that Ubuntu might have done in their default install?)

Also, I don't think that you can have an absolute path to a CGI like that... unless you have ServerRoot set to /, and that is really not recommended for security issues.

Anyway, here's what I normally do when running PHP as a module:

AddType application/x-httpd-php .php
LoadModule php5_module modules/libphp5.so

Does that help?

(no subject)

Date: 2007-09-07 03:35 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
I am, indeed, restarting it after the changes. I'm *getting* all kinds of different results from different attempts. It's just that none of them are working.

And I don't want to run it as a module, *or* I want to change the existing module to use my new build of PHP from source. I don't care which. However, the only libphp5.so file I have is the existing one.

(no subject)

Date: 2007-09-07 03:41 pm (UTC)
From: [identity profile] giza.livejournal.com
Normally, building PHP should result in a module file being somewhere under the build directory. Assuming you're doing it from the command line, try this after your build completes:

find . libphp5.so

If that doesn't turn up anything, then you might want to take a closer look at the options that are being passed in to configure. I would not be surprised in the least if one of the options suppresses creation of the module file, and is not properly documented as doing so. (Back in the days of PHP 3, building it used to be a gigantic mess. Things have gotten better since then, but I still find PHP as being non-trivial to build as of version 5...)


(no subject)

Date: 2007-09-07 04:18 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
You know, it takes a SHOCKING amount of digging to find out that you need to use --enable-so to get a .so file.

As in, it's NOT IN THE DOCUMENTATION ITSELF, only in the examples.

(no subject)

Date: 2007-09-07 04:10 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
In fact, at the moment I have a perfectly working way to redirect calls to .php5 files to the place of my choice.

My problem is that I can't put the php.cgi executable that I want to use, into that location of choice. I simply can't find out what I need to use in that second line to make the server find the executable.

Do you have any suggestions? Or, alternately, do you know how to *change* the module?

(no subject)

Date: 2007-09-07 04:21 pm (UTC)
From: [identity profile] giza.livejournal.com
> My problem is that I can't put the php.cgi executable that I want to use,
> into that location of choice. I simply can't find out what I need to use in
> that second line to make the server find the executable.

That would be due to the ServerRoot issue. And I strongly recommend against setting ServerRoot to /.

Have you looked in php.ini options at all?

The module file is a binary, so it cannot just "changed". (nor would you want to) It is usually replaced with with a new one that is compiled.

(no subject)

Date: 2007-09-07 05:35 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
I'm trying to run it as a cgi, not a module...
OR I'm trying to make it build a new module.

And it's not letting me build a new module.

(no subject)

Date: 2007-09-07 06:22 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
In fact, I don't care where the binary is. I can put it *anywhere* I want it, regardless of server root or whatever, *and* I have the added bonus of this server never being exposed to the public.

I just need to be able to make it run a copy of PHP with non-standard options.

(no subject)

Date: 2007-09-07 03:44 pm (UTC)
From: [identity profile] jsbowden.livejournal.com
If you want to use it as an Apache module, you have to recompile Apache with the new module. If it's already compiled with the old module built in, you need to recompile it without it if you want it as a non-module. At least, that's how apache used to handle modules. I haven't built apache in a very long time, so maybe it uses dynamically loaded modules now, but I wouldn't count on it, as that is a security nightmare.

(no subject)

Date: 2007-09-07 04:13 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
a2enmod/a2dismod let you dynamically enable and disable modules. I can disable the existing php5 and replace the .so file and re-enable it, all I want. The problem is that I don't have a new .so file. I wonder how I go about telling that to build?

Okay. Assume, then, that I don't want it as a module, and that all I really want is to be able to run it through cgi-bin. Do you know what I'd have to do to tell Apache the location of the binary I want it to use?

(no subject)

Date: 2007-09-07 04:19 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
You know, it takes a SHOCKING amount of digging to find out that you need to use --enable-so to get a .so file.

As in, it's NOT IN THE DOCUMENTATION ITSELF, only in the examples.

Yet another reason programmers must die...

Date: 2007-09-07 05:08 pm (UTC)
From: [identity profile] jsbowden.livejournal.com
I don't even read build docs anymore if something uses autoconf, I just run ./configure --help and then rerun it with the options I want from the list of what gets spit out.

Re: Yet another reason programmers must die...

Date: 2007-09-07 05:36 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
Even worse: That command is wrong, and silently fails to produce what the results say it should.

DEATH DEATH DEATH DEATH DEATH

(no subject)

Date: 2007-09-07 06:27 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
Well, now I have a new .so file, but it doesn't do me any good because apache doesn't want to load it, only the original file.

Dammit, how hard can it possibly be to tell the system "when reading php files in X location, use Y php executable"?

This is making me stupid.

(no subject)

Date: 2007-09-10 03:51 am (UTC)
From: [identity profile] quotation.livejournal.com
Best Practices, Words of Wisdom, Voice of Experience, etc. etc. etc.

First, don't "rebuild the source," -- instead, "rebuild the package." Standing on the shoulders of giants, and all that.

Also, I find that running two versions of PHP simultaneously usually implies that there's a "weird reason" at play. When faced with the kinds of "weird reasons" that lead to these misadventures, I usually recommend running multiple apaches instead.

Let's say that http(s)://some.domain.name/ is a module-light highly optimized apache. It probably has the SSL modules and whatnot, serves up the static /images/ and maybe even runs some compiled C SOAP services. It's got the proxy-pass module, though. Any hits to /webmail/ are transparently proxied to http://localhost:8001/squirrelmail/, which has no SSL, and exactly the webserver versions that your squirrelmail installation prefers. /fileshare/ is a proxypass to your sharepoint server on a windows vmware slice, and /twiki/ to another localhost port running just the right versions of its junk, too.

Sure, it sounds weird, but it works really, really, really well. ProxyPass is one of the best tricks I've ever learned.

(no subject)

Date: 2007-09-10 04:03 am (UTC)
From: [identity profile] theweaselking.livejournal.com
I'm always glad to take your tips, because I know you've got a lot more practice at this than I have.

What if I *just want to change the PHP options for all sites, on the entire system, all at once*?

I want the entire system to use a different PHP. That's it, that's all. I currently have a package-installed Apache-2 with a package-installed PHP-as-apache-module. There is no package for the PHP option I want. I therefore need to build my own PHP, and tell apache to use my new PHP.

However, when I build my own PHP-as-CGI, I can't make apache run it. When I build my own PHP-as-module and replace the existing one, apache won't read it. This, frankly, tells me that even if I *do* make a new apache, I won't be able to make my new PHP work with it.

And, really, it's the new PHP that is the problem.

Got a suggestion for where to look, for this?

(no subject)

Date: 2007-09-10 04:16 am (UTC)
From: [identity profile] quotation.livejournal.com
To get the whole system to use a different PHP, then build a new PHP RPM from the same source package as your previous PHP RPM. Change the bare minimum, and restrict your changes to patches and .spec file changes.

Replace your old PHP RPM with your new one, completely uninstalling the old one.

If RPM is not your package manager of choice, uh, I dunno.

Not following this advice guarantees a soon-to-be-discovered remote root exploit in the source you compiled from, and you'll have to start all over again, at the worst possible time. Been there, done that, even got a TShirt. Spec files are real easy to diff, and Red Hat is actually really good at keeping their spec files and patch files pretty clean.

(no subject)

Date: 2007-09-10 12:55 pm (UTC)
From: [identity profile] theweaselking.livejournal.com
apt, not RPM, so the packages are .deb, but same principle.

Except, of course, that I've never done it before, so it will take me three times as long as it should.

Do you know anything about setting up PHP-as-cgi? As in, what I'm doing wrong with my attempt to pass .php5 files to a PHP binary rather than the standard way? I've got the standard php-as-module shortcutted, so it doesn't go there any more for .php5 files, I just can't get it to find the CGI one. If I can get *that* working, then I can redirect all the other PHP files through the CGI binary, uninstall the PHP module completely, and then simply replace the PHP.cgi file any time I need to make changes in the future.

In fact, if I wanted to set up a server-side program to run ".bob" or ".joe" files, would you know how to tell apache to do it? If I can make that work, I can make PHP work.

Profile

theweaselking: (Default)theweaselking
Page generated Feb. 5th, 2026 05:01 pm