Re: Anyone interested in a patch to mod_fcgid(with pay)
On Tue, 23 Jul 2013 09:46:58 +0800 (CST) Pqf 潘庆峰 wrote: > Yes, split process control from mod_fcgid, merge proxy_fcgi(with > load balance) and mod_fcgid(with authXX support) is a good idea, > admins can use httpd as process manager, or 3rd party process > managers as they like. But don't just make a patch to make mod_fcgid > support TCP/IP, it's ugly... Nice synopsis :)
[PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files
Hello everyone, We're looking at moving our shared hosting execution behind mod_fcgid and suexec, but we need to continue to allow our users .htaccess 'Files' overrides. The current mod_fcgid allows users to execute arbitrary commands by configuring the FcgidAccessChecker, FcgidAuthenticator, FcgidAuthorizer, and FcgidWrapper directives within .htaccess files. - https://issues.apache.org/bugzilla/show_bug.cgi?id=49220 I've approached a fix by creating a directive that would disable the application of those directives within .htaccess files if set; that patch has been submitted to the httpd bug 49220. You might shrewdly wonder "how can this matter - this is cgi after all, we're just going to try to exec the resulting file!", but we're able to get away from that by disabling ExecCGI globally and setting it per-request in separate module which also ensures the request is mapped to our specific FcgidWrapper. I see mod_fcgid 2.3.8 is closing in a few days; any chance to sneak this in? Thanks for your time and consideration. Ben
Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
On Thu, Jul 5, 2012 at 7:01 PM, wrote:
> Author: chrisd
> Date: Thu Jul 5 23:01:09 2012
> New Revision: 1357986
>
> URL: http://svn.apache.org/viewvc?rev=1357986&view=rev
> Log:
> Avoid internal sub-requests and processing of Location headers when
> in FCGI_AUTHORIZER mode, as the mod_fcgid_authenticator(), etc. hook
> functions report an error if the script returned a Location header and
> redirections are nonsensical in this mode.
>
> Previously, the handle_request_ipc() and handle_request() functions would
> examine this header when in FCGI_AUTHORIZER mode and then possibly execute
> an internal sub-request, which has no particular use, as its return value
> is ignored and its output may conflict with that of the actual content
> generation phase.
>
>From the FastCGI spec (6.3):
"For Authorizer response status values other than "200" (OK), the Web
server denies access and sends the response status, headers, and content
back to the HTTP client."
I was initially confused when looking at this commit (nothing like
reviewing one year later) wondering if it broke this requirement, but
AFAICT 2.3.7 didn't support the feature anyway, so no regression. (Some
iff statements in this code are what control it.)
> Modified:
> httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
>
> Modified: httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
> URL:
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c?rev=1357986&r1=1357985&r2=1357986&view=diff
>
> ==
> --- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c (original)
> +++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c Thu Jul 5 23:01:09
> 2012
> @@ -320,6 +320,10 @@ handle_request_ipc(request_rec *r, int r
> return cond_status;
> }
>
> +if (role == FCGI_AUTHORIZER) {
> +return cond_status;
> +}
> +
> /* Check redirect */
> location = apr_table_get(r->headers_out, "Location");
>
> @@ -347,9 +351,8 @@ handle_request_ipc(request_rec *r, int r
> }
>
> /* Now pass to output filter */
> -if (role == FCGI_RESPONDER
> -&& (rv = ap_pass_brigade(r->output_filters,
> - brigade_stdout)) != APR_SUCCESS) {
> +if ((rv = ap_pass_brigade(r->output_filters,
> + brigade_stdout)) != APR_SUCCESS) {
> if (!APR_STATUS_IS_ECONNABORTED(rv)) {
> ap_log_rerror(APLOG_MARK, APLOG_WARNING, rv, r,
>"mod_fcgid: ap_pass_brigade failed in "
>
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
Jeff Trawick wrote: URL: http://svn.apache.org/viewvc?rev=1357986&view=rev <http://svn.apache.org/viewvc?rev=1357986&view=rev> Log: Avoid internal sub-requests and processing of Location headers when in FCGI_AUTHORIZER mode, as the mod_fcgid_authenticator(), etc. hook functions report an error if the script returned a Location header and redirections are nonsensical in this mode. Previously, the handle_request_ipc() and handle_request() functions would examine this header when in FCGI_AUTHORIZER mode and then possibly execute an internal sub-request, which has no particular use, as its return value is ignored and its output may conflict with that of the actual content generation phase. From the FastCGI spec (6.3): "For Authorizer response status values other than "200" (OK), the Web server denies access and sends the response status, headers, and content back to the HTTP client." I was initially confused when looking at this commit (nothing like reviewing one year later) wondering if it broke this requirement, but AFAICT 2.3.7 didn't support the feature anyway, so no regression. (Some iff statements in this code are what control it.) Yes, I believe that's correct (it's been a while). It's a really good question and worth having a second pair of eyes. I did a smidge of testing today, comparing 2.3.7 and trunk, with a test Authorizer that returns things like 403, 500, etc. I believe there's no difference for most of these cases; the 2.3.7 behaviour is to return a 401, which is still the case. (This may not follow the spec, as you point out, but is the existing behaviour; I'll double-check on that tomorrow.) The intent of r1357986 was to deal with a particular, wonky sub-case, when the Authorizer returns 200 (so the spec paragraph doesn't apply in this case, as it's a 200 OK response), but adds a Location header with a relative (not absolute) path. In this case, 2.3.7 and previous will run the sub-request and return whatever comes out of that -- sometimes munging the end result as a consequence. (Note that a 200 with an absolute URL in a Location header just produces a 401 response.) For example, if the Authorizer returns "Location: /cgi-bin/printenv" and a 200, you get something strange like: HTTP/1.1 200 OK ... CONTEXT_PREFIX="/cgi-bin/" ... SERVER_SOFTWARE="Apache/2.5.0-dev (Unix) mod_fcgid/2.3.7" 200 Unknown Reason Unknown Reason ... Or if the Location is bad (say, "Location: /cgi-bin/printenv.FOO") then you get a 404 with a "200 Unknown Reason" glued on: HTTP/1.1 404 Not Found ... 404 Not Found Not Found The requested URL /cgi-bin/printenv.FOO was not found on this server. 200 Unknown Reason So r1357986 is just trying to handle those 200 OK + "Location: /..." header cases. If it does more than that, we should review further, but that was the only intent ... IIRC after about a year or so. Chris. -- GPG Key ID: 088335A9 GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
Chris Darroch wrote: The intent of r1357986 was to deal with a particular, wonky sub-case, when the Authorizer returns 200 (so the spec paragraph doesn't apply in this case, as it's a 200 OK response), but adds a Location header with a relative (not absolute) path. In this case, 2.3.7 and previous will run the sub-request and return whatever comes out of that -- sometimes munging the end result as a consequence. (Note that a 200 with an absolute URL in a Location header just produces a 401 response.) Actually, I have to take back that last parenthetical note -- with 2.3.7, a 200 + absolute Location URL produces a 302 + Location header, and with trunk, it produces a 401 like other 200 + Location header cases. That might be, I suppose, considered a regression ... let me think on it a bit. It's not covered by the spec case you mention, since the script is returning 200. The 2.3.7 behaviour is inconsistent depending on the nature of the URL in the Location header, given a 200. Trunk makes that behaviour consistent, but perhaps that's a regression? Hmm. Chris. -- GPG Key ID: 088335A9 GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
On Thu, Oct 3, 2013 at 1:06 AM, Chris Darroch wrote: > Chris Darroch wrote: > > The intent of r1357986 was to deal with a particular, wonky >> sub-case, when the Authorizer returns 200 (so the spec paragraph >> doesn't apply in this case, as it's a 200 OK response), but adds >> a Location header with a relative (not absolute) path. In this case, >> 2.3.7 and previous will run the sub-request and return whatever comes >> out of that -- sometimes munging the end result as a consequence. >> (Note that a 200 with an absolute URL in a Location header just produces >> a 401 response.) >> > > Actually, I have to take back that last parenthetical note -- > with 2.3.7, a 200 + absolute Location URL produces a 302 + Location header, > and with trunk, it produces a 401 like other 200 + Location header cases. > > That might be, I suppose, considered a regression ... let me > think on it a bit. It's not covered by the spec case you mention, since > the script is returning 200. The 2.3.7 behaviour is inconsistent depending > on the nature of the URL in the Location header, given a 200. Trunk > makes that behaviour consistent, but perhaps that's a regression? Hmm. The app is out of spec either way. I think the trunk behavior is better. > > Chris. > > -- > GPG Key ID: 088335A9 > GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9 > > -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
Jeff Trawick wrote: The app is out of spec either way. I think the trunk behavior is better. I'd agree on both counts (the latter IMHO, of course). For reference, here's a breakdown of 2.3.7 vs. trunk behaviour for Authorizers: Authorizer response2.3.7 trunk ==== = 200proceed proceed 200 + rel Location 200 + munged out + err 401 200 + bad rel Location 404 + munged err + err 401 200 + abs Location 302 + Location 401 all other 401 401 I'll try to run some quick smoke tests on your 2.3.9 over the weekend; thanks again for pushing this along. Chris. -- GPG Key ID: 088335A9 GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: [EMAIL PROTECTED] Apache Win32 Binary, mod_perl and mod_fcgid working
Steffen wrote: > To inform you. > > We at http://www.apachelounge.com made a binary available which works > with mod-perl and mod-perl etc. How did the perl-framework regression tests look; and which patch did you happen to use? Or is this the cobbled-together 2.2.6 + smattering of 2.2.5 sources? I'd personally encourage anyone who didn't need piped logs to hold back at 2.2.4 till there's a 2.2.7 ready to fly. Bill
Re: [EMAIL PROTECTED] Apache Win32 Binary, mod_perl and mod_fcgid working
On Tue, 25 Sep 2007 16:20:00 -0500 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Steffen wrote: > > To inform you. > > > > We at http://www.apachelounge.com made a binary available which > > works with mod-perl and mod-perl etc. > > How did the perl-framework regression tests look; and which patch did > you happen to use? Or is this the cobbled-together 2.2.6 + > smattering of 2.2.5 sources? Presumably it could be something as simple as 2.2.6 with older APR. Or the relevant hacks to the thrid-party modules in question. > I'd personally encourage anyone who didn't need piped logs to hold > back at 2.2.4 till there's a 2.2.7 ready to fly. That's a valid option (I'm on 2.2.5 for my live server). But choice is a Good Thing, and Steffen is offering it to his users. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: [EMAIL PROTECTED] Apache Win32 Binary, mod_perl and mod_fcgid working
Nick Kew wrote: > On Tue, 25 Sep 2007 16:20:00 -0500 > "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > >> Steffen wrote: >>> To inform you. >>> >>> We at http://www.apachelounge.com made a binary available which >>> works with mod-perl and mod-perl etc. >> How did the perl-framework regression tests look; and which patch did >> you happen to use? Or is this the cobbled-together 2.2.6 + >> smattering of 2.2.5 sources? > > Presumably it could be something as simple as 2.2.6 with older APR. > Or the relevant hacks to the thrid-party modules in question. Actually no, the "flaw" here in relation to modperl lies in mpm_winnt combined with perl combined with Microsoft's MSVCR[T|70|71|80].dll. The fcgid-type issues were a result of the newest APR which is what you must be thinking of. Bill
Re: [EMAIL PROTECTED] Apache Win32 Binary, mod_perl and mod_fcgid working
William A. Rowe, Jr. wrote: Steffen wrote: To inform you. We at http://www.apachelounge.com made a binary available which works with mod-perl and mod-perl etc. How did the perl-framework regression tests look; and which patch did you happen to use? Or is this the cobbled-together 2.2.6 + smattering of 2.2.5 sources? re: "which patch" - There are a few notes and a pointer to the patches at: http://www.apachelounge.com/forum/viewtopic.php?p=8903#8903 It is 2.2.6/APR 1.2.11 with changes. Nothing from 2.2.5 or APR 1.2.9. I didn't run the perl-framework regression tests (I'm not familiar with them). I'd personally encourage anyone who didn't need piped logs to hold back at 2.2.4 till there's a 2.2.7 ready to fly. Definitely! While this set of patches works, and therefore may yield some clues about the mod_perl problem - it remains unexplained *why* it works, so it cannot be considered trustworthy IMHO. The FastCGI part is well understood (needs INVALID_HANDLE_VALUE). The mod_perl part (mpm_winnt) is still a bit mysterious. A guess - mod_perl failed because of some interaction between stdin/stdout and the Windows console devices CONIN$/CONOUT$. -tom-
Re: svn commit: r813174 - /httpd/mod_fcgid/trunk/docs/manual/mod/mod_fcgid.xml
On Wed, Sep 9, 2009 at 9:06 PM, William A. Rowe, Jr. wrote: > traw...@apache.org wrote: > > Author: trawick > > Date: Wed Sep 9 23:41:17 2009 > > New Revision: 813174 > > > > URL: http://svn.apache.org/viewvc?rev=813174&view=rev > > Log: > > alphabetize the directives > > Thanks, it's good to see other people jump on this :) > I just hope that the presence of a first draft for some of the directives doesn't discourage anyone else from digging in and adding to or correcting what is there now ;)
Re: svn commit: r816757 - /httpd/mod_fcgid/trunk/docs/manual/mod/mod_fcgid.xml
On Fri, Sep 18, 2009 at 3:37 PM, wrote: > Author: trawick > Date: Fri Sep 18 19:37:56 2009 > New Revision: 816757 > > URL: http://svn.apache.org/viewvc?rev=816757&view=rev > Log: > add a couple of example configurations > F I X M E !
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
On Sat, Sep 19, 2009 at 3:48 AM, Marcus Merz wrote:
> Hi,
>
> i ran into a problem with mod_fcgid and i wonder whether anybody can
> replicate my problem.
>
> There is also a bug report in here:
>
> http://sourceforge.net/tracker/?func=detail&aid=2854396&group_id=174879&atid=870991
>
>
Any PHP experts out there?
The basic problem from your description is that PHP thinks the .jpg file is
the PHP script and tries to parse that (instead of modify.php). I easily
duplicated that.
I then looked up the setting of cgi.fix_pathinfo. My php.ini has a comment
that says it defaults to 1. mod_fcgid has a setting that is supposed to
mirror that (PHP_Fix_Pathinfo_Enable). So I set "PHP_Fix_Pathinfo_Enable 1"
in my mod_fcgid configuration, but still no change in failure.
I then edited php.ini, set cgi.fix_pathinfo=0, set "PHP_Fix_Pathinfo_Enable
0" (the default) in my mod_fcgid conf, and retested.
Now PHP is trying to run modify.php instead of interpreting a .jpg file
(good!). It fails to open the file properly ("*Warning*:
getimagesize(./wtmrk./IMG_4418.jpg)") but that may be something about how I
attempted to set up modify.php.
So set "cgi.fix_pathinfo=0" in the proper* php.ini and try again. (*You may
have a separate one for mod_php vs. "CGI"; set the latter one.)
BTW, here were the request environment settings sent over by mod_fcgid:
SCRIPT_FILENAME=/home/trawick/inst/22/htdocs/modify.php
REDIRECT_URL=/wtmrk/IMG_4418.jpg
REQUEST_URI=/wtmrk/IMG_4418.jpg
SCRIPT_NAME=/modify.php
PATH_INFO=/wtmrk/IMG_4418.jpg
PATH_TRANSLATED=/home/trawick/wtmrk/IMG_4418.jpg
Another way to look at it is to consider if mod_fcgid is doing the right
thing when PHP_Fix_Pathinfo_Enable is 1 (matching PHP's default). I don't
know about that ;)
That logic (in mod_fcgid.c) is as follows:
/* "DOCUMENT_ROOT"/"SCRIPT_NAME" -> "SCRIPT_NAME" */
const char *doc_root = apr_table_get(e, "DOCUMENT_ROOT");
const char *script_name = apr_table_get(e, "SCRIPT_NAME");
if (doc_root && script_name
&& apr_filepath_merge(&merge_path, doc_root, script_name, 0,
r->pool) == APR_SUCCESS) {
apr_table_setn(e, "SCRIPT_NAME", merge_path);
}
In our example, the Action for wtmrk is defined as "/modify.php", so
SCRIPT_NAME is "/modify.php" when we get here. apr_filepath_merge() just
returns the 3rd parameter when it starts with "/", so our supposedly-merged
script name is unchanged. That's not what I would have expected. (Also, I
wonder what happens when SCRIPT_NAME is outside of DOCUMENT_ROOT.)
Recap: Try cgi.fix_pathinfo=0; maybe somebody else will chime in on the
PHP_Fix_Pathinfo_Enable processing.
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
Hi Jeff, "Jeff Trawick" schrieb im Newsbeitrag news:... > On Sat, Sep 19, 2009 at 3:48 AM, Marcus Merz wrote: > > Recap: Try cgi.fix_pathinfo=0; maybe somebody else will chime in on the > PHP_Fix_Pathinfo_Enable processing. > Thanks for your comments. Surprisingly setting cgi.fix_pathinfo=0 in php.ini does not change the behaviour calling http://www.domain.tld/image.jpg . PHP still tries to parse the jpg, same as with the default setting of cgi.fix_pathinfo=1in php.ini. What *does* change is, that when calling http://www.domain.tld/modify.php/image.php (for test purposes) instead of displaying the image -which worked before with cgi.fix_pathinfo=1 (or uncommented as 1 is default), PHP tries to parse the jpg as well: Warning: Unexpected character in input: '' (ASCII=16) state=1 in /srv/www/vhosts/image.jpg on line 234 Parse error: syntax error, unexpected '[' in /srv/www/vhosts/image.jpg on line 234 I did check with phpinfo() that cgi.fix_pathinfo was 0 and 1 each time i tested. What is new is, that using CGI instead of mod_fcgid, with cgi.fix_pathinfo=0 the script now fails with a 'No input file specified' message in the webbrowser. There is no error logged in error_log but a 404 is logged in access_log for /image.jpg. Obviously using mod_php it works regardless of setting cgi.fix_pathinfo=0 or 1 as it is not taken care of anyway and so the image gets displayed each time. To recap: setting cgi.fix_pathinfo=0 causes mod_fcgid to parse the jpg file (same behaviour as before) using http://www.domain.tld/image.jpg *AND* http://www.domain.tld/modify.php/image.php Switching back to cgi.fix_pathinfo=1 and using CGI instead of mod_fcgid, the image gets displayed 'out-of-the-box. I suspect there are differences in mod_fcgid.conf which default settings cause this behaviour because the php.ini is the same for both. I will take a closer look into the docs for 2.3.1 and trying to find a solution there. Of course i was glad if somebody else knows the solution. Thanks, Marcus
Virtual Hosts & FCGI paths, was Re: [VOTE] release httpd mod_fcgid-2.3.1?
Hi, I spoke a little too soon, there is one problem. mod_fcgid correctly uses the VirtualHost as one of the unique inputs for each backend daemon. (Sidenote: This virtualhost code is *only* present in the unix process manager, which means there is a separate bug/issue in the win32 process manager code) And while this is technically correct, it causes a problem for *.apache.org. As you know, we have something like 70+ TLPs. While they are all running the same FastCGI script, each one of these TLPs has their own subdomain, and therefore mod_fcgid is treating their scripts as different process groups. Since we have so many TLPs (go us!), we were looking at roughly 300 mirror.fcgi processes running on our production web server, while if we were to 'fake' it under one vhost, I believe it would only be 10. Index: fcgid_pm_unix.c === --- fcgid_pm_unix.c (revision 817154) +++ fcgid_pm_unix.c (working copy) @@ -434,7 +434,7 @@ command->deviceid = deviceid; command->inode = inode; command->share_grp_id = share_grp_id; -command->virtualhost = r->server->server_hostname; +command->virtualhost = "apache.org's setup is awesome"; /* Update fcgid_command with wrapper info */ command->wrapperpath[0] = '\0'; While, this is obviously a terrible thing for a general purpose module, I would like to propose that we add a 'FCGIIgnoreVirtualHost' configuration option, which would set the vhost field to a constant value, so FCGI processes would be shared between virtual hosts. ps, patch is deployed to apache.org right now :) . > BTW, we are now running mod_fcgid trunk in production for www.apache.org. > > wiki.apache.org (MoinMoin powered) is now running in FastCGI mode, via > mod_fcgid. > > I also hacked up all of the download,cgi/mirror.cgi scripts, so they > are running via fastcgi too ( <http://httpd.apache.org/download.cgi>, > <http://www.apache.org/dyn/mirrors/mirrors.cgi>, etc) > > eating the dogfood quite well right now... :) > > -Paul >
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
On Sun, Sep 20, 2009 at 12:30 PM, Marcus Merz wrote: > Hi Jeff, > > "Jeff Trawick" schrieb im Newsbeitrag > news:... > > On Sat, Sep 19, 2009 at 3:48 AM, Marcus Merz wrote: > > > > Recap: Try cgi.fix_pathinfo=0; maybe somebody else will chime in on the > > PHP_Fix_Pathinfo_Enable processing. > > > > Thanks for your comments. Surprisingly setting cgi.fix_pathinfo=0 in > php.ini > does not change the behaviour calling http://www.domain.tld/image.jpg . What is your configuration to run modify.php as a CGI? Do you add a shebang line, or use something else? Here's my configuration: LoadModule fcgid_module modules/mod_fcgid.so Allow from all AddHandler wtmrk jpg Action wtmrk /modify.php SetHandler fcgid-script FCGIWrapper /usr/bin/php5-cgi .php SetHandler cgi-script Options +ExecCGI Allow from all I comment out the LoadModule directive to switch to CGI. I had to add a shebang line to the top of modify.php.
Re: svn commit: r817350 - /httpd/mod_fcgid/trunk/docs/manual/mod/mod_fcgid.xml
On Mon, Sep 21, 2009 at 1:59 PM, wrote: > Author: rjung > Date: Mon Sep 21 17:59:23 2009 > New Revision: 817350 > > URL: http://svn.apache.org/viewvc?rev=817350&view=rev > Log: > > ... > - Adding the other two compatibility notes from README to the > upgrade section > > ... > + Some directives which could be placed inside > <VirtualHost > but were > + ignored before now result in configuration errors. As before, these > + directives must be set at global scope to have the desired effect. > + These include module="mod_fcgid">FCGIDIdleTimeout, > + FCGIDMaxProcessCount, > + FCGIDPHPFixPathinfoEnable, > + FCGIDProcessLifetime, and > others. > + (Consult CHANGES-FCGID for the complete list.) > + > + Some directives which can optionally be placed inside > <VirtualHost > > + were not inherited as expected in older releases. This has been > + corrected, and behavior will change for some configurations. > Affected > + directives include module="mod_fcgid">FCGIDIPCCommTimeout, > + FCGIDOutputBufferSize, and > others. > + (Consult CHANGES-FCGID for the complete list.) > I think the less said about migration in the reference docs the better. In particular, I don't think these two issues need to be described in the reference docs, as they describe only misbehaving or ignored aspects of old configurations. (And generally the docs shouldn't point to CHANGES for additional information.)
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
"Jeff Trawick" schrieb im Newsbeitrag
news:cc67648e0909210827h6247d05fu65c31252b6f32...@mail.gmail.com...
>What is your configuration to run modify.php as a CGI? Do you add a
>shebang line, or use something else?
>
>Here's my configuration:
>
>LoadModule fcgid_module modules/mod_fcgid.so
>
>
> Allow from all
> AddHandler wtmrk jpg
> Action wtmrk /modify.php
>
>
>
>
>
>SetHandler fcgid-script
>FCGIWrapper /usr/bin/php5-cgi .php
>
>
>
>SetHandler cgi-script
>
>
> Options +ExecCGI
> Allow from all
>
>
>I comment out the LoadModule directive to switch to CGI. I had to add a
>shebang line to the top of modify.php.
>
I use Plesk 9.2.1 (on OpenSUSE 10.3) to define my domains/virtual hosts. For
PHP I can choose between 'Apache Module', 'FastCGI-Application' and
'CGI-Application'. I will skip the settings for Apache Module here.
Depending on what you select, Plesk does adjust the corresponding
httpd.include for the respective domain (i.e. virtual host). Furthermore i
use support for perl and python. The httpd.include sits in
/srv/www/vhosts/domain.tld/conf and is included from
/etc/apache2/conf.d/zz010_psa_httpd.conf (which gets included from
/etc/apache2/httpd.conf).
General configuration from /etc/apache2/sysconfig.d/loadmodule.conf (i left
out non-php-relevant entries):
---
LoadModule cgi_module
/usr/lib64/apache2-prefork/mod_cgi.so
LoadModule php5_module/usr/lib64/apache2/mod_php5.so
LoadModule fcgid_module /usr/lib64/apache2/mod_fcgid.so
LoadModule suexec_module
/usr/lib64/apache2-prefork/mod_suexec.so
---
Both CGI and FastCGI use
:/usr/bin/ # php-cgi5 -v
PHP 5.2.9 with Suhosin-Patch 0.9.7 (cgi-fcgi) (built: Mar 12 2009 16:17:38)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
In my php.ini i have
; cgi.force_redirect is necessary to provide security running PHP as a CGI
under
; most web servers. Left undefined, PHP turns this on by default. You can
; turn it off here AT YOUR OWN RISK
; **You CAN safely turn this off for IIS, in fact, you MUST.**
; http://php.net/cgi.force-redirect
;cgi.force_redirect = 1
so it defaults to 1 which is why i set the same in mod_fcgid.conf via
'PHP_Fix_Pathinfo_Enable 1'.
a) Settings for using CGI
/etc/apache2/conf.d/php_cgi.conf
---
scriptAlias /phppath/ "/usr/bin/"
Action php-script /phppath/php-cgi5
---
/srv/www/vhosts/domain.tld/conf/httpd.include
---
:80>
SetHandler perl-script
PerlHandler ModPerl::Registry
Options ExecCGI
allow from all
PerlSendHeader On
SetHandler python-program
PythonHandler mod_python.cgihandler
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
AddHandler php-script .php
Options +ExecCGI
allow from all
Options -Includes -ExecCGI
Include /srv/www/vhosts/domain.tld/conf/vhost.conf
b) Settings for using FastCGI which is mod_fcgid is selected form Plesk:
:80>
...
SetHandler perl-script
PerlHandler ModPerl::Registry
Options ExecCGI
allow from all
PerlSendHeader On
SetHandler python-program
PythonHandler mod_python.cgihandler
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
SetHandler fcgid-script
FCGIWrapper /usr/bin/php-cgi5 .php
Options +ExecCGI
allow from all
Options -Includes -ExecCGI
Include /srv/www/vhosts/domain.tld/conf/vhost.conf
/etc/apache2/conf.d/mod_fcgid.conf
---
##
## Sample config for apache2_mod-fcgid
##
## All lines, that are commented out, reflect the default values.
##
##
## An idle fastcgi application will be terminated after IdleTimeout seconds.
##
#IdleTimeout 300
##
## The scan interval for idle fastcgi applications in seconds.
##
#IdleScanInterval 120
##
## a fastcgi application will be terminated if handing a single request
longer
## than busy timeout. Value in seconds.
##
#BusyTimeout 300
##
## The scan interval for busy timeout fastcgi applications. Value in
seconds.
##
#BusyScanInterval 120
##
##
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
As an additional note, i found another watermark script which fails with the
same error (it will need the same .htaccess as in my first post - save the
script as modify.php as well or adjust the name in .htaccess accordingly) as
PHP will try to parse the jpg file instead of displaying the image.
Again, switching to cgi-fcgi or mod_php, the image gets displayed
(differences between mod_fcgid and mod_cgi as shown in the httpd.include in
my previous post):
---
http://creativecommons.org/licenses/by/2.5/
//
// The following line must reside in any derivative works:
//
// portions (cc) Doncho Angelov 2005 (http://doncho.net)
//
// -
//
//
// SETUP
//
// the location of the picture, which contains the normal watermark
// (we first try to apply this one)
define(BIG_WATERMARK_FILE, $_SERVER['DOCUMENT_ROOT'] . "/watermark.jpg");
// the location of the picture, which contains the smaller watermark
// (for the images, which are smaller than 5 times the normal watermark)
define(SMALL_WATERMARK_FILE, $_SERVER['DOCUMENT_ROOT'] . "/watermark.jpg");
// SETUP ends
// generate the image with watermark
function watermark($source, $outputType="") {
// determine the type of the source image
$sourceType = getFileType($source);
// output the header of the new image
if (empty($outputType)) $outputType = $sourceType;
// if you hate GIF files, you can switch to PNG
if ($outputType == "gif") $outputType = "png";
header("Content-type:image/$outputType");
// create the source
$createSource = "ImageCreateFrom".strtoupper($sourceType);
$showImage = "Image".strtoupper($outputType);
$output = $createSource($source);
// load the big logo
$logo = loadWatermark(BIG_WATERMARK_FILE);
// check if the watermark is not bigger than the logo
if (ImageSX($output)<(ImageSX($logo)*5) ||
ImageSY($output)<(ImageSY($logo)*5))
// if so, fallback to a smaller logo
$logo = loadWatermark(SMALL_WATERMARK_FILE);
$x = ImageSX($output) - ImageSX($logo);
$y = ImageSY($output) - ImageSY($logo);
ImageAlphaBlending($output, true);
ImageCopy($output, $logo, $x, $y, 0, 0, ImageSX($logo), ImageSY($logo));
$showImage($output);
ImageDestroy($output);
ImageDestroy($logo);
}
function getFileType($string)
{
$type = strtolower(eregi_replace("^(.*\.)","",$string));
if ($type == "jpg") $type = "jpeg";
return $type;
}
function loadWatermark($watermarkFile)
{
$watermarkType = getFileType($watermarkFile);
$createWatermark = "ImageCreateFrom".strtoupper($watermarkType);
return $createWatermark($watermarkFile);
}
//
// main functionality starts here
//
$image = $_SERVER["PATH_TRANSLATED"];
if (empty($image)) die();
if (!file_exists($image))
{
header("404 Not Found");
echo "Requested File Not Found."; die();
}
$outputType = getFileType($image);
watermark($image, $outputType);
?>
---
I wonder whether i have a special environment which causes this behaviour
only with me. Otherwise i would expect a lot more 'noise' from other people
when switching to mod_fcgid from either mod_php or mod_fastcgi as these
scripts will fail.
Regards,
Marcus
Re: svn commit: r817350 - /httpd/mod_fcgid/trunk/docs/manual/mod/mod_fcgid.xml
On 21.09.2009 20:11, Jeff Trawick wrote: > On Mon, Sep 21, 2009 at 1:59 PM, <mailto:rj...@apache.org>> wrote: > > Author: rjung > Date: Mon Sep 21 17:59:23 2009 > New Revision: 817350 > > URL: http://svn.apache.org/viewvc?rev=817350&view=rev > <http://svn.apache.org/viewvc?rev=817350&view=rev> > Log: > > ... > > > - Adding the other two compatibility notes from README to the > upgrade section > > ... > > > + Some directives which could be placed inside > <VirtualHost > but were > + ignored before now result in configuration errors. As > before, these > + directives must be set at global scope to have the desired > effect. > + These include module="mod_fcgid">FCGIDIdleTimeout, > + FCGIDMaxProcessCount, > + module="mod_fcgid">FCGIDPHPFixPathinfoEnable, > + module="mod_fcgid">FCGIDProcessLifetime, and others. > + (Consult CHANGES-FCGID for the complete list.) > + > + Some directives which can optionally be placed inside > <VirtualHost > > + were not inherited as expected in older releases. This has been > + corrected, and behavior will change for some configurations. > Affected > + directives include module="mod_fcgid">FCGIDIPCCommTimeout, > + module="mod_fcgid">FCGIDOutputBufferSize, and others. > + (Consult CHANGES-FCGID for the complete list.) > > > > I think the less said about migration in the reference docs the better. > In particular, I don't think these two issues need to be described in > the reference docs, as they describe only misbehaving or ignored aspects > of old configurations. (And generally the docs shouldn't point to > CHANGES for additional information.) Done.
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
On Mon, Sep 21, 2009 at 2:24 PM, Marcus Merz wrote: > > "Jeff Trawick" schrieb im Newsbeitrag > news:cc67648e0909210827h6247d05fu65c31252b6f32...@mail.gmail.com... > > >What is your configuration to run modify.php as a CGI? Do you add a > >shebang line, or use something else? > > > >Here's my configuration: > Thanks for the additional details. > > In my php.ini i have > > ; cgi.force_redirect is necessary to provide security running PHP as a CGI > under > ; most web servers. Left undefined, PHP turns this on by default. You can > ; turn it off here AT YOUR OWN RISK > ; **You CAN safely turn this off for IIS, in fact, you MUST.** > ; http://php.net/cgi.force-redirect > ;cgi.force_redirect = 1 > > so it defaults to 1 which is why i set the same in mod_fcgid.conf via > 'PHP_Fix_Pathinfo_Enable 1'. > I'm not aware of a connection between cgi.force_redirect and PHP_Fix_Pathinfo_Enable. What do you know about that? > a) Settings for using CGI > > For the purposes of my recreate, I condensed this down to AddHandler php-script .php ScriptAlias /phppath/ /usr/bin/ Action php-script /phppath/php5-cgi Allow from all AddHandler php-script .php Options +ExecCGI Allow from all > b) Settings for using FastCGI which is mod_fcgid is selected form Plesk: > > For the purposes of my recreate, I condensed this down to SetHandler fcgid-script FCGIWrapper /usr/bin/php5-cgi .php Options +ExecCGI Allow from all AddHandler php-script .php Action php-script /phppath/php5-cgi Allow from all AddHandler php-script .php Options +ExecCGI Allow from all As before, this only came close to working for me with cgi.fix_pathinfo=0. With the CGI configuration in hand, then I tried to convert that directly to FastCGI. Theoretically we should just change the handler from cgi-script to fcgid-script and it should work. But the CGI configuration uses ScriptAlias as a short-cut for Alias /phppath/ /usr/bin/ SetHandler cgi-script Options +ExecCGI When I use that expansion of ScriptAlias, and convert the cgi-script to fcgid-script, I now get this for the FastCGI configuration: AddHandler php-script .php # ScriptAlias /phppath/ /usr/bin/ Alias /phppath/ /usr/bin/ SetHandler fcgid-script Options +ExecCGI Action php-script /phppath/php5-cgi Allow from all AddHandler php-script .php Options +ExecCGI Allow from all That's the direct translation of the CGI configuration to a FastCGI configuration. And the script works for me now via FastCGI, without changing cgi.fix_pathinfo to 0. (I'm not setting PHP_Fix_PathInfo_Enable either.) > So depending on what i set in Plesk the httpd.include file gets changed and > php files get parsed either with module mod_cgi.so or mod_fcgid.so (which > is > a symlink to the 2.3.1 version i compiled) and both times with the same > binary /usr/bin/php-cgi5. > > At least that is my understanding. > > AFAICT, if Plex was creating a mod_fcgid configuration that was an exact translation from the mod_cgi configuration, it would work with mod_fcgid. > > There is another difference looking at phpinfo(): > > Using mod_fcgid the only Environment variable i see is PATH. Using mod_cgi > there are a whole lot more Envrionment variables. To my understanding > variables shown under 'Environment' are Apache ENV variables. > That is to be expected. The CGI process is created for every request, so the Apache subprocess env data is passed over as a native/OS environment variable when the process is created. The FastCGI process is started and intended to be run for many different requests; the Apache subprocess env data is passed over on a socket with the actual request. The important stuff is populated in _SERVER[]. > > phpinfo() from CGI via http://www.domain.tld/admin/phpinfo.php: > > Environment > VariableValue > PATH/usr/local/bin:/usr/bin:/bin > REDIRECT_STATUS200 > HTTP_HOSTwww.domain.tld > HTTP_USER_AGENTMozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) > Gecko/20090824 Firefox/3.5.3 GTB5 (.NET CLR 3.5.30729) > HTTP_ACCEPT > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > HTTP_ACCEPT_LANGUAGEde > HTTP_ACCEPT_ENCODINGgzip > HTTP_ACCEPT_CHARSETISO-8859-1,utf-8;q=0.7,*;q=0.7 > HTTP_KEEP_ALIVE300 > HTTP_CONNECTIONkeep-alive > HTTP_COOKIE*** > SERVER_SOFTWAREApache/2.2.13 (Linux/SUSE) > SERVER_NAMEdomain.tld > SERVER_ADDR > SERVER_PORT80 > REMOTE_ADDR > DOCUMENT_ROOT/srv/www/vhosts/domain.tld/httpdocs > SERVER_ADMIN*** > SCRIPT_FILENAME/srv/www/vhosts/domain
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
Hi Jeff,
"Jeff Trawick" schrieb im Newsbeitrag
news:cc67648e0909211455i5cb6c7c3ub4fdcc25cb9cc...@mail.gmail.com...
On Mon, Sep 21, 2009 at 2:24 PM, Marcus Merz wrote:
>In my php.ini i have
>
>; cgi.force_redirect is necessary to provide security running PHP as a CGI
>under
>; most web servers. Left undefined, PHP turns this on by default. You can
>; turn it off here AT YOUR OWN RISK
>; **You CAN safely turn this off for IIS, in fact, you MUST.**
>; http://php.net/cgi.force-redirect
>;cgi.force_redirect = 1
>
>so it defaults to 1 which is why i set the same in mod_fcgid.conf via
>'PHP_Fix_Pathinfo_Enable 1'.
>
>
>I'm not aware of a connection between cgi.force_redirect and
>PHP_Fix_Pathinfo_Enable. What do you know about that?
>
I am sorry. It was meant to read:
; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for
CGI. PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to
not grok
; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs.
Setting
; this to 1 will cause PHP CGI to fix its paths to conform to the spec. A
setting
; of zero causes PHP to behave as before. Default is 1. You should fix
your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; http://php.net/cgi.fix-pathinfo
;cgi.fix_pathinfo=1
I copied the wrong part from my php.ini. Also for the missing environment
variables i should have tested from the same conditions but i did
http://domain.tld/phpinfo.php on mod_fcgid config and
http://www.domain.tld/admin/phpinfo.php on the mod_cgi config. A difference
in variables is to be expected then. I will get back to this later today and
retest.
...
>>I hope this clearifies the situation a lot more instead of causing even
>>more
>>confusion.
>
>
>Yes, it helps a lot.
>
>
>
>>I was happy to give you even more information if you told me what you
>>need.
>>I would really like to get this solved (and apologies concerning the
>>formatting of these variables).
>
>
>No problem.
>
>Please try translating the CGI config directly to FastCGI as noted above,
>instead of using the Plesk-generated config, and let us know what happens.
>
>Replace this bit
>
>
>SetHandler fcgid-script
>FCGIWrapper /usr/bin/php-cgi5 .php
>Options +ExecCGI
>Allow from all
>
>
>with
>
>Alias /phppath/ /usr/bin/
>
>SetHandler fcgid-script
>Options +ExecCGI
>
>
I get a configuration error when i try to do replace that bit (in the lines
where i put a *) and 'rcapache2 reload' after because that part sits in a
VirtualHost container nested within . The first error was: "Alias
not allowed here":
:80>
...
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
*
*SetHandler fcgid-script
*FCGIWrapper /usr/bin/php-cgi5 .php
*Options +ExecCGI
*allow from all
*
Options -Includes -ExecCGI
Include /srv/www/vhosts/domain.tld/conf/vhost.conf
but i got your point. I will try to replicate your setup later today.
At least i am glad to hear that the script works with mod_fcgid if using the
same config than with mod_cgi.
Rgds,
Marcus
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
Ok, i am puzzled
"Jeff Trawick" schrieb im Newsbeitrag
news:cc67648e0909211455i5cb6c7c3ub4fdcc25cb9cc...@mail.gmail.com...
Please try translating the CGI config directly to FastCGI as noted above,
instead of using the Plesk-generated config, and let us know what happens.
Replace this bit
SetHandler fcgid-script
FCGIWrapper /usr/bin/php-cgi5 .php
Options +ExecCGI
Allow from all
with
Alias /phppath/ /usr/bin/
SetHandler fcgid-script
Options +ExecCGI
I could not get it to work in my httpd.include file as Apache was always
throwing an error (i.e. Alias not allowed here, Location not allowed here
etc).
I ended up changing my /etc/apache2/conf.d/mod_fcgid.conf (excerpt) from:
---
##
## PHP via FastCGI
##
## uncomment the following line if you want to handle php via mod_fcgid
##
#
#AddHandler fcgid-script .php
#FCGIWrapper /srv/www/cgi-bin/php5 .php
#Options +ExecCGI
#
##
# End of
##
---
to
---
##
## PHP via FastCGI
##
## uncomment the following line if you want to handle php via mod_fcgid
##
#
#AddHandler fcgid-script .php
#FCGIWrapper /srv/www/cgi-bin/php5 .php
#Options +ExecCGI
#
##
Alias /phppath/ "/usr/bin/"
SetHandler fcgid-script
Options +ExecCGI
# End of
##
so basically inserting your replacement code at the bottom inside the container.
Now there are two things:
1) On virtual hosts which use 'FastCGI-Application' in Plesk and which
httpd.include looks like this:
:80>
...
SetHandler perl-script
PerlHandler ModPerl::Registry
Options ExecCGI
allow from all
PerlSendHeader On
SetHandler python-program
PythonHandler mod_python.cgihandler
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
SetHandler fcgid-script
FCGIWrapper /usr/bin/php-cgi5 .php
Options +ExecCGI
allow from all
Options -Includes -ExecCGI
Include /srv/www/vhosts/domain.tld/conf/vhost.conf
a) I sometimes get all files offered to download (not really able to replicate
this, it seems it is connected to the use of .htaccess and modify.php in the
same directory i sometimes get php files with image/jpeg header for download,
sometimes with x-httpd-php header...kind of bizarre...) and
b) The watermark image still fails for the same reason as stated before: PHP
tries to parse the image.
I have proof that this config uses mod_fcgid because phpinfo() gives only
_ENV["PATH"] under Environment plus i do get a _SERVER["Authorization"] and
other Auth variables when calling phpinfo() from a .htaccess secured directory
(AuthType Basic) which was not the case if it was mod_cgi.
2) Virtual hosts which use 'CGI-Application' in Plesk and which httpd.include
therefore looks like this:
:80>
...
SetHandler perl-script
PerlHandler ModPerl::Registry
Options ExecCGI
allow from all
PerlSendHeader On
SetHandler python-program
PythonHandler mod_python.cgihandler
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
AddHandler php-script .php
Options +ExecCGI
allow from all
Options -Includes -ExecCGI
Include /srv/www/vhosts/domain.tld/conf/vhost.conf
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
AddHandler php-script .php
Options +ExecCGI
allow from all
the watermark image gets displayed and phpinfo() states that mod_fcgid is used.
When in 2. you would choose 'FastCGI-Application' in Plesk which causes the
httpd.include (excerpt) to look like this:
SetHandler fcgid-script
Options +FollowSymLinks +ExecCGI
SetHandler fcgid-script
FCGIWrapper /usr/bin/php-cgi5 .php
Options +ExecCGI
allow from all
the watermark image fails
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
Hi Jeff, after another evening, this is what i came up with: Goals: 1. I do not want to mess around with /etc/apache2/conf.d/mod_fcgid.conf 2. I do not want to be forced to always use mod_fcgid on virtual hosts that are configured for mod_cgi (from Plesk) I achieve this by doing all necessary changes in /srv/www/vhosts//conf/vhost.conf (in case of a subdomain ist could also be /srv/www/vhosts/domain.tld/subdomains//conf/vhost.conf) and amending the respective httpd.include file (in /srv/www/vhosts//conf as well). The downside is, that this httpd.include file gets generated by Plesk whenever you change anything for that virtual host or a subdomain for that virtual host. There is an event manager in Plesk where you can specify to run a specific script after an event has taken place like 'hosting domain create/update' to reverse any changes to httpd.include but it would require more work and knowledge to write such a script, i.e. cutting the respective container (see below) and adding necessary code either in httpd.include or a vhost.conf file. Certainly it is doable, though. Fine. [btw, maybe it was my fault but using your replacement code 1:1 causes every file (tested with php or jpeg) to be offered for download by the browser (tested on 2 different computers with FF 3.5.3, IE 6 and IE 8)] To get mod_fcgid running with this watermark script and not to interfere with virtual hosts configured to use mod_cgi, i did amend/extend a couple of things, plus, i did add FCGIWrapper statement back in which might be useless but i wanted to know whether that directive is part of the problem. Actually it is not. The problem starts when using 'SetHandler fcgid-sript' instead of an Alias/Action combination. /etc/apache2/conf.d/mod_fcgid.conf is back to 'out-of-the-box' configuration. I only added PassHeader Authorization PHP_Fix_Pathinfo_Enable 1 like before. My httpd.include is: :80> ... SetHandler perl-script PerlHandler ModPerl::Registry Options ExecCGI allow from all PerlSendHeader On SetHandler python-program PythonHandler mod_python.cgihandler SetHandler fcgid-script Options +FollowSymLinks +ExecCGI # # # SetHandler fcgid-script # FCGIWrapper /usr/bin/php-cgi5 .php # Options +ExecCGI # allow from all # # Options -Includes -ExecCGI Include /srv/www/vhosts/domain.tld/conf/vhost.conf so you could skip/delete the second container from httpd.include. The included vhost.conf file then contains: --- Alias /phpfcgidpath/ "/usr/bin/" Action php-fcgid /phpfcgidpath/php-cgi5 SetHandler fcgid-script Options +ExecCGI SetHandler php-fcgid FCGIWrapper /usr/bin/php-cgi5 .php Options +ExecCGI allow from all --- The first two statements are basically similiar to the /etc/apache2/conf.d/php_cgi.conf (and needed as i did replace /phppath/ with /phpfcgidpath/ for which there is no ScriptAlias and Action statement in any other *.conf file): --- scriptAlias /phppath/ "/usr/bin/" Action php-script /phppath/php-cgi5 --- As i wanted to have a testconfig which does not interfere with mod_cgi, i changed from /phppath/ to /phpfcgidpath/ and did use Alias instead of ScriptAlias because you used it in your replacement bit. In the end it does not really matter. This causes only virtual hosts which have this additional statement in its vhost.conf to use mod_fcgid and the watermark image works with this configuration. As soon as you change the SetHandler statement in the vhost.conf from: SetHandler php-fcgid FCGIWrapper /usr/bin/php-cgi5 .php Options +ExecCGI allow from all to SetHandler fcgid-script FCGIWrapper /usr/bin/php-cgi5 .php Options +ExecCGI allow from all (which is the default from Plesk in httpd.include when switching to FastCGI-Application), PHP tries to parse the jpg file again. This is expected as changing the SetHandler directive as shown, the Alias and Action directive are not used anymore as we do not use the Handler php-fcgid anymore and we are back to square one. Using this 'workaround' does have one other side-effect: As we are using a Alias (or ScriptAlias) directive, now, when we call an URL from a .htaccess protected directory -AuthType Basic in connection with PassHeader Authrization-, the _SERVER["REMOTE_USER"] variable is empty and _ENV["REDIRECT_REMOTE_USER"] is used instead. This is not really a problem, but when you tr
Re: svn commit: r818242 - in /httpd/mod_fcgid/trunk: CHANGES-FCGID Makefile.apxs
Guys, I think we missed one... traw...@apache.org wrote: > Author: trawick > Date: Wed Sep 23 20:31:44 2009 > New Revision: 818242 > > URL: http://svn.apache.org/viewvc?rev=818242&view=rev > Log: > Fix a make install DESTDIR problem handling the reference manual. > The currently-unused rule for installing header files was also > fixed. > > This only affected our 2.3.1 beta release. > > Submitted by: Paul Howarth > Reviewed by: trawick > > Modified: > httpd/mod_fcgid/trunk/CHANGES-FCGID > httpd/mod_fcgid/trunk/Makefile.apxs > > Modified: httpd/mod_fcgid/trunk/CHANGES-FCGID > URL: > http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/CHANGES-FCGID?rev=818242&r1=818241&r2=818242&view=diff > ========== > --- httpd/mod_fcgid/trunk/CHANGES-FCGID [utf8] (original) > +++ httpd/mod_fcgid/trunk/CHANGES-FCGID [utf8] Wed Sep 23 20:31:44 2009 > @@ -1,6 +1,10 @@ > -*- coding: utf-8 > -*- > Changes with mod_fcgid 2.3.2 > > + *) Fix a make install DESTDIR problem handling the reference manual and > + potentially other files (specific to 2.3.1). > + [Paul Howarth ] > + >*) Fix a mod_fcgid 2.3.1 failure with when building for > httpd 2.0.x on some platforms. [Paul Howarth ] > > > Modified: httpd/mod_fcgid/trunk/Makefile.apxs > URL: > http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/Makefile.apxs?rev=818242&r1=818241&r2=818242&view=diff > == > --- httpd/mod_fcgid/trunk/Makefile.apxs (original) > +++ httpd/mod_fcgid/trunk/Makefile.apxs Wed Sep 23 20:31:44 2009 Before these changes, below, Makefile.apxs offers up; httpd_conffile=$(exp_sysconfdir)/$(progname).conf which is used later in the makefile for; @awk -f $(fcgid_srcdir)/build/addloadexample.awk \ -v MODULE=fcgid -v DSO=.so -v LIBPATH=$(rel_libexecdir) \ -v EXAMPLECONF=$(rel_sysconfdir)/extra/httpd-fcgid.conf \ $(httpd_conffile) > $(httpd_conffile).new && \ ( mv $(httpd_conffile) $(httpd_conffile).bak && \ mv $(httpd_conffile).new $(httpd_conffile) ); Won't this need to be changed also to? httpd_conffile=$(DESTDIR)$(exp_sysconfdir)/$(progname).conf I have a commit ready if you confirm. > @@ -94,21 +94,21 @@ > > install-manual: > @echo Installing online manual > - @test -d $(exp_manualdir) \ > - || $(MKINSTALLDIRS) $(exp_manualdir) > + @test -d $(DESTDIR)$(exp_manualdir) \ > + || $(MKINSTALLDIRS) $(DESTDIR)$(exp_manualdir) > @if test "x$(RSYNC)" != "x" && test -x $(RSYNC) ; then \ > $(RSYNC) --exclude .svn -rlpt --numeric-ids \ > - $(fcgid_srcdir)/docs/manual/ $(exp_manualdir)/; \ > + $(fcgid_srcdir)/docs/manual/ $(DESTDIR)$(exp_manualdir)/; \ > else \ > - cp -rp $(fcgid_srcdir)/docs/manual/* $(exp_manualdir)/ && \ > - find $(exp_manualdir) -name ".svn" -type d -print \ > + cp -rp $(fcgid_srcdir)/docs/manual/* $(DESTDIR)$(exp_manualdir)/ && \ > + find $(DESTDIR)$(exp_manualdir) -name ".svn" -type d -print \ > | xargs rm -rf 2>/dev/null || true; \ > fi > > install-include: > @echo Installing header files > - @$(MKINSTALLDIRS) $(exp_includedir) && \ > - cp $(fcgid_srcdir)/include/mod_fcgid.h $(exp_includedir)/ && \ > - chmod 0644 $(exp_includedir)/mod_fcgid.h > + @$(MKINSTALLDIRS) $(DESTDIR)$(exp_includedir) && \ > + cp $(fcgid_srcdir)/include/mod_fcgid.h $(DESTDIR)$(exp_includedir)/ > && \ > + chmod 0644 $(DESTDIR)$(exp_includedir)/mod_fcgid.h > > .PHONY: generate-dox generate-docs > > > >
Re: svn commit: r818242 - in /httpd/mod_fcgid/trunk: CHANGES-FCGID Makefile.apxs
On 24/09/09 21:37, William A. Rowe, Jr. wrote: Guys, I think we missed one... traw...@apache.org wrote: Author: trawick Date: Wed Sep 23 20:31:44 2009 New Revision: 818242 URL: http://svn.apache.org/viewvc?rev=818242&view=rev Log: Fix a make install DESTDIR problem handling the reference manual. The currently-unused rule for installing header files was also fixed. This only affected our 2.3.1 beta release. Submitted by: Paul Howarth Reviewed by: trawick Modified: httpd/mod_fcgid/trunk/CHANGES-FCGID httpd/mod_fcgid/trunk/Makefile.apxs Modified: httpd/mod_fcgid/trunk/CHANGES-FCGID URL: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/CHANGES-FCGID?rev=818242&r1=818241&r2=818242&view=diff == --- httpd/mod_fcgid/trunk/CHANGES-FCGID [utf8] (original) +++ httpd/mod_fcgid/trunk/CHANGES-FCGID [utf8] Wed Sep 23 20:31:44 2009 @@ -1,6 +1,10 @@ -*- coding: utf-8 -*- Changes with mod_fcgid 2.3.2 + *) Fix a make install DESTDIR problem handling the reference manual and + potentially other files (specific to 2.3.1). + [Paul Howarth] + *) Fix a mod_fcgid 2.3.1 failure with when building for httpd 2.0.x on some platforms. [Paul Howarth] Modified: httpd/mod_fcgid/trunk/Makefile.apxs URL: http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/Makefile.apxs?rev=818242&r1=818241&r2=818242&view=diff == --- httpd/mod_fcgid/trunk/Makefile.apxs (original) +++ httpd/mod_fcgid/trunk/Makefile.apxs Wed Sep 23 20:31:44 2009 Before these changes, below, Makefile.apxs offers up; httpd_conffile=$(exp_sysconfdir)/$(progname).conf which is used later in the makefile for; @awk -f $(fcgid_srcdir)/build/addloadexample.awk \ -v MODULE=fcgid -v DSO=.so -v LIBPATH=$(rel_libexecdir) \ -v EXAMPLECONF=$(rel_sysconfdir)/extra/httpd-fcgid.conf \ $(httpd_conffile)> $(httpd_conffile).new&& \ ( mv $(httpd_conffile) $(httpd_conffile).bak&& \ mv $(httpd_conffile).new $(httpd_conffile) ); Won't this need to be changed also to? httpd_conffile=$(DESTDIR)$(exp_sysconfdir)/$(progname).conf I have a commit ready if you confirm. I think it's best to prepend $(DESTDIR) in front of any reference to $(httpd_conffile) on the destination. Whilst this is more long-winded than simply adding $(DESTDIR) into $(httpd_conffile) at source, it avoids errors that might creep in if the value of $(httpd_conffile) was used in any other context, such as embedding it into documentation or startup scripts, where you don't want to see $(DESTDIR). Paul.
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
Is this issue solved in 2.3.4? Regards, Marcus
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
On Sun, Oct 11, 2009 at 6:16 AM, Marcus Merz wrote: > Is this issue solved in 2.3.4? no
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
On Mon, Oct 12, 2009 at 4:14 PM, Jeff Trawick wrote: > On Sun, Oct 11, 2009 at 6:16 AM, Marcus Merz wrote: >> Is this issue solved in 2.3.4? > > no BTW, I'm sorry I haven't followed up to your last couple of posts. I should be honest with you: All that Plesk-generated config and/or attempts to interject tweaks to that config makes my head explode. Maybe somebody else here has the time and will power to dig through it. My general thoughts: I don't think mod_fcgid's processing can be compared to mod_php's in any meaningful way. Instead, it should be compared to mod_cgi's (mod_cgid's). FastCGI is essentially CGI, but with the request information passed over in a way that allows the script to handle multiple requests without exiting. mod_cgi and mod_fcgid should pass the same request environment variables to the CGI/FastCGI application, and in fact they use the same core httpd code to build that information. (The notable exception is when FcgidFixPathInfo is turned on, in which case mod_fcgid modifies one of the request environment variables I can't say if/when exactly that helps.) Good luck!
Re: svn commit: r823703 - in /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_proc_unix.c
--- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_proc_unix.c 2009/10/08
14:32:38 823190
+++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_proc_unix.c 2009/10/08
14:35:13 823191
@@ -259,6 +259,17 @@
return errno;
}
+/* IPC directory permissions are safe, but avoid confusion */
+/* Not all flavors of unix use the current umask for AF_UNIX perms */
+
+rv = apr_file_perms_set(unix_addr.sun_path,
APR_FPROT_UREAD|APR_FPROT_UWRITE|APR_FPROT_UEXECUTE);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_CRIT, rv, main_server,
+ "mod_fcgid: Couldn't set permissions on unix domain socket
%s",
+ unix_addr.sun_path);
+return rv;
+}
+
/* Listen the socket */
if (listen(unix_socket, DEFAULT_FCGID_LISTENBACKLOG) < 0) {
ap_log_error(APLOG_MARK, APLOG_ERR, errno, main_server,
This change breaks compatibility with old APR versions. Attached patch
seems to fix it for me.
Paul.
Index: modules/fcgid/fcgid_proc_unix.c
===
--- modules/fcgid/fcgid_proc_unix.c (revision 827986)
+++ modules/fcgid/fcgid_proc_unix.c (working copy)
@@ -43,6 +43,17 @@
#include "fcgid_pm.h"
#include "fcgid_spawn_ctl.h"
+/* apr forward compatibility */
+#ifndef APR_FPROT_UWRITE
+#define APR_FPROT_UWRITEAPR_UWRITE
+#endif
+#ifndef APR_FPROT_UREAD
+#define APR_FPROT_UREAD APR_UREAD
+#endif
+#ifndef APR_FPROT_UEXECUTE
+#define APR_FPROT_UEXECUTE APR_UEXECUTE
+#endif
+
#if MODULE_MAGIC_NUMBER_MAJOR < 20081201
#define ap_unixd_config unixd_config
// #define ap_unixd_setup_child unixd_setup_child
Re: svn commit: r823703 - in /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_proc_unix.c
On Wed, Oct 21, 2009 at 8:54 AM, Paul Howarth wrote:
>> --- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_proc_unix.c 2009/10/08
>> 14:32:38 823190
>> +++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_proc_unix.c 2009/10/08
>> 14:35:13 823191
>> @@ -259,6 +259,17 @@
>> return errno;
>> }
>>
>> + /* IPC directory permissions are safe, but avoid confusion */
>> + /* Not all flavors of unix use the current umask for AF_UNIX perms */
>> +
>> + rv = apr_file_perms_set(unix_addr.sun_path,
>> APR_FPROT_UREAD|APR_FPROT_UWRITE|APR_FPROT_UEXECUTE);
>> + if (rv != APR_SUCCESS) {
>> + ap_log_error(APLOG_MARK, APLOG_CRIT, rv, main_server,
>> + "mod_fcgid: Couldn't set permissions on unix domain
>> socket %s",
>> + unix_addr.sun_path);
>> + return rv;
>> + }
>> +
>> /* Listen the socket */
>> if (listen(unix_socket, DEFAULT_FCGID_LISTENBACKLOG) < 0) {
>> ap_log_error(APLOG_MARK, APLOG_ERR, errno, main_server,
>
> This change breaks compatibility with old APR versions. Attached patch seems
> to fix it for me.
Thanks.
I think I'll put the #defines inside "#if (APR_MAJOR_VERSION < 1)"
instead of using "ifndef APR_FPROT_foo" so that readers know instantly
what that is about.
[mod_fcgid PATCH] display elapsed instead of absolute time in server status
to represent when process was started and when it was last used.
Any concerns with this somewhat gratuitous change?
(also changes "Requests handled" to "Accesses")
now:
Pid Active IdleAccessesState
30890 99 0 1479Ready
and after all such tables:
"Active and Idle are time active and time since last request, in seconds."
before:
Pid Start time Last active timeRequest handled State
18135 1258059310 1258059318 126 Ready
17670 1258059285 1258059327 732 Ready
17671 1258059286 1258059327 948 Ready
18136 1258059310 1258059327 294 Ready
17672 1258059287 1258059320 331 Ready
Index: modules/fcgid/mod_fcgid.c
===
--- modules/fcgid/mod_fcgid.c (revision 901434)
+++ modules/fcgid/mod_fcgid.c (working copy)
@@ -295,6 +295,7 @@
gid_t last_gid = 0;
uid_t last_uid = 0;
apr_size_t last_share_grp_id = 0;
+apr_time_t now;
const char *last_virtualhost = NULL;
const char *basename, *tmpbasename;
fcgid_procnode *proc_table = proctable_get_table_array();
@@ -353,6 +354,8 @@
}
proctable_unlock(r);
+now = apr_time_now();
+
/* Sort the array */
if (num_ent != 0)
qsort((void *)ar, num_ent, sizeof(fcgid_procnode *),
@@ -383,8 +386,8 @@
/* Create a new table for this process info */
ap_rputs("\n\n"
- "PidStart timeLast active time"
- "Requests handledState"
+ "PidActiveIdle"
+ "AccessesState"
"\n", r);
last_inode = current_node->inode;
@@ -396,13 +399,18 @@
}
ap_rprintf(r, "%" APR_PID_T_FMT "%" APR_TIME_T_FMT
"%" APR_TIME_T_FMT "%d%s",
- current_node->proc_id.pid,
apr_time_sec(current_node->start_time),
- apr_time_sec(current_node->last_active_time),
+ current_node->proc_id.pid,
+ apr_time_sec(now - current_node->start_time),
+ apr_time_sec(now - current_node->last_active_time),
current_node->requests_handled,
get_state_desc(current_node));
}
-if (num_ent != 0)
+if (num_ent != 0) {
ap_rputs("\n\n", r);
+ap_rputs("\n"
+ "Active and Idle are time active and time
since\n"
+ "last request, in seconds.\n", r);
+}
return OK;
}
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
"Jeff Trawick" schrieb im Newsbeitrag
news:cc67648e0910121343j7e922d94q1f96ee89cd897...@mail.gmail.com...
> On Mon, Oct 12, 2009 at 4:14 PM, Jeff Trawick wrote:
>> On Sun, Oct 11, 2009 at 6:16 AM, Marcus Merz wrote:
>>> Is this issue solved in 2.3.4?
>>
>> no
>
> BTW, I'm sorry I haven't followed up to your last couple of posts. I
> should be honest with you: All that Plesk-generated config and/or
> attempts to interject tweaks to that config makes my head explode.
> Maybe somebody else here has the time and will power to dig through
> it.
...
> Good luck!
>
Well, it's been a while but as i want other people to find a solution should
they dig in old archives via Google, i wanted to share wiht you how i got
around 'the wonderful world of Plesk' (no, i did not deinstall it...).
Please acknowledge that i am neither a guru of Apache, mod_fcgid nor PHP. I
simply want to help people who might face the same problem than i did about
6 months ago. If you read this whole thread, then you know about the
problems arising in certain -special- environments when you want to use
mod_fcgid (i.e. active watermarking images like i did).
My current environment as of writing this is:
- suse-10.3-x86_64-plesk9
- Plesk 9.2.3
- Apache 2.2.4 with MPM-worker enabled
- PHP 5.2.9
- mod_fcgid 2.3.5 (with 'FcgidFixPathinfo 1' in
/etc/apache2/conf.d/mod_fcgid.conf)
The 'FcgidFixPathinfo 1' in /etc/apache2/conf.d/mod_fcgid.conf corresponds
to
---
; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for
CGI. PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to
not grok
; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs.
Setting
; this to 1 will cause PHP CGI to fix its paths to conform to the spec. A
setting
; of zero causes PHP to behave as before. Default is 1. You should fix
your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; http://php.net/cgi.fix-pathinfo
;cgi.fix_pathinfo=1
---
in /etc/php5/fastcgi/php.ini as cgi.fix_pathinfo=1 is the default. I mention
it here because i refer to it later.
To avoid problems in an active watermark php script (caused by SetHandler
and FCGIWrapper directives - please read the entire thread for details),
this is what i did:
In Plesk, choose "PHP Support via CGI" from the dropdown menue in your
"Web Hosting Setup".
This will add
---
AddHandler php-script .php
Options +ExecCGI
allow from all
---
to your /conf/httpd.include file. Now, how do we get to use
mod_fcgid then?
In /etc/sysconfig/apache2 you (hopefully) have:
---
APACHE_MODULES=" cgi fcgid suexec"
---
so mod_fcgid.so will be included in
/etc/apache2/sysconfig.d/loadmodule.conf.
In the order you included your modules above, mod_cgi.so will be implemented
before mod_fcgid.so and therefore /etc/apache2/conf.d/php_cgi.conf will be
parsed before /etc/apache2/conf.d/mod_fcgid.conf. Do i make sense?
What does this mean?
In /etc/apache2/conf.d/php_cgi.conf we have
---
scriptAlias /phppath/ "/usr/bin/"
Action php-script /phppath/php-cgi5
---
(this was mentioned in here before). Actually this causes all PHP scripts to
be parsed by mod_cgi. Hmm Fine. Let's add a vhost.conf in
/srv/www/vhosts//conf/
like this: /srv/www/vhosts//conf/vhost.conf
---
Include /srv/www/vhosts/global.vhost.conf
---
What? This is because i want ALL domains to use PHP via mod_fcgid yet i do
not want to change every vhost.conf manually which is why i use this
'Include'.
/srv/www/vhosts/global.vhost.conf:
---
Alias /phpfcgidpath/ "/usr/bin/"
Action php-script /phpfcgidpath/php-cgi5
SetHandler fcgid-script
Options +ExecCGI
---
Now, what do we do here? Well, we define an alias similiar like in
/etc/apache2/conf.d/php_cgi.conf but via the Action statement and the
following Location container, all Files ending (\.php) will now get parsed
using mod_fcgid because of the
---
SetHandler fcgid-script
---
If you have set 'FcgidFixPathinfo 1' in
/etc/apache2/conf.d/mod_fcgid.conf -as explained above- calling phpinfo()
will tell you this
---
_SERVER["ORIG_SCRIPT_NAME"] /phpfcgidpath/php-cgi5
---
which means, mod_fcgid has been used to parse the php file. This is what we
wanted to achieve.
Instead of using a (global) vhost.conf file, you could probably put
everything into /etc/apache2/conf.d/mod_fcgid.conf but this is like with
Rome: There are more than one ways to achieve your goal. I just wrote about
how I succeeded. Feel free to find your own way.
HTH.
Marcus
Re: mod_fcgid: Problem serving binary content with Apache 2.2.13 - PHP 5.2.9
On Tue, Feb 23, 2010 at 4:47 PM, Marcus Merz wrote: > Well, it's been a while but as i want other people to find a solution should > they dig in old archives via Google, Thanks for the good summary.
Re: Patches for mod_fcgid welcome? remove-FCGID_DIE_COMM_ERROR-processes, increase-INITENV_VAL_LEN, disable_suexec_check
On Tue, Aug 17, 2010 at 10:34 AM, Erik Wasser wrote: > Hello list, > > I've prepared some (mini-)patches for mod_fcgid 2.3.5 that I want to get > rid > off (read: they can be included in the next release). > better to start separate threads, one for each patch, with the patch
Re: Patch for disabling the suexec stuff (Patch: mod_fcgid-2.3.5-disable_suexec_check.patch)
On Fri, Oct 22, 2010 at 5:32 AM, Erik Wasser wrote: > I've added an extra option to mod_fcgid to turn off the suexec stuff. It's > useful if you want to run the apache as non-root user and you need the speed > of mod_fcgid. > > The default value is - of course - 0. The configuration line is very simple: > > [...Other Fcgid options...] > FcgidDisableSuexecCheck 1 > [...] This should just work out of the box. We need to check if mod_fcgid is behaving differently than other modules (e.g., mod_cgid), or if general behavior is just busted. I'll try to look into this "soon" unless someone else reports back.
Re: Patch for disabling the suexec stuff (Patch: mod_fcgid-2.3.5-disable_suexec_check.patch)
On 22/10/10 13:35, Jeff Trawick wrote: On Fri, Oct 22, 2010 at 5:32 AM, Erik Wasser wrote: I've added an extra option to mod_fcgid to turn off the suexec stuff. It's useful if you want to run the apache as non-root user and you need the speed of mod_fcgid. The default value is - of course - 0. The configuration line is very simple: [...Other Fcgid options...] FcgidDisableSuexecCheck 1 [...] This should just work out of the box. We need to check if mod_fcgid is behaving differently than other modules (e.g., mod_cgid), or if general behavior is just busted. I'll try to look into this "soon" unless someone else reports back. Not being able to turn off suexec in mod_fcgid has been a long-standing issue in Fdora: https://bugzilla.redhat.com/show_bug.cgi?id=523903 Is there any chance of Erik's patch or something similar being in the upcoming release? Paul.
Re: Patch for disabling the suexec stuff (Patch: mod_fcgid-2.3.5-disable_suexec_check.patch)
On Thu, Nov 4, 2010 at 6:16 AM, Paul Howarth wrote: > On 22/10/10 13:35, Jeff Trawick wrote: >> >> On Fri, Oct 22, 2010 at 5:32 AM, Erik Wasser >> wrote: >>> >>> I've added an extra option to mod_fcgid to turn off the suexec stuff. >>> It's >>> useful if you want to run the apache as non-root user and you need the >>> speed >>> of mod_fcgid. >>> >>> The default value is - of course - 0. The configuration line is very >>> simple: >>> >>> [...Other Fcgid options...] >>> FcgidDisableSuexecCheck 1 >>> [...] >> >> This should just work out of the box. We need to check if mod_fcgid >> is behaving differently than other modules (e.g., mod_cgid), or if >> general behavior is just busted. I'll try to look into this "soon" >> unless someone else reports back. > > Not being able to turn off suexec in mod_fcgid has been a long-standing > issue in Fdora: > > https://bugzilla.redhat.com/show_bug.cgi?id=523903 > > Is there any chance of Erik's patch or something similar being in the > upcoming release? The one rolled today? No. (But we should have more frequent releases anyway.) IMO this goes in mod_unixd (trunk) or os/unix/unixd.c (older releases) to override the usual suexec enablement. Something like Suexec On# startup fails if suexec isn't usable Suexec Off# suexec disabled even if usable (I suspect some small trick is needed with this since, at least in trunk, the determination is made in a pre-config hook. Is that what EXEC_ON_READ is for? Maybe there are other surprises.)
Re: Patch for disabling the suexec stuff (Patch: mod_fcgid-2.3.5-disable_suexec_check.patch)
On Thu, Nov 4, 2010 at 6:51 AM, Jeff Trawick wrote: > IMO this goes in mod_unixd (trunk) or os/unix/unixd.c (older releases) > to override the usual suexec enablement. Something like > > Suexec On # startup fails if suexec isn't usable > Suexec Off # suexec disabled even if usable > > (I suspect some small trick is needed with this since, at least in > trunk, the determination is made in a pre-config hook. Is that what > EXEC_ON_READ is for? Maybe there are other surprises.) patch to add global Suexec On/Off flag just posted for comments; if there's nothing inherently problematic about it, perhaps we can get it into future httpd 2.4 as well as httpd 2.2.next
Re: Patch for disabling the suexec stuff (Patch: mod_fcgid-2.3.5-disable_suexec_check.patch)
On Tue, Nov 9, 2010 at 10:32 AM, Jeff Trawick wrote: > On Thu, Nov 4, 2010 at 6:51 AM, Jeff Trawick wrote: >> IMO this goes in mod_unixd (trunk) or os/unix/unixd.c (older releases) >> to override the usual suexec enablement. Something like >> >> Suexec On # startup fails if suexec isn't usable >> Suexec Off # suexec disabled even if usable >> >> (I suspect some small trick is needed with this since, at least in >> trunk, the determination is made in a pre-config hook. Is that what >> EXEC_ON_READ is for? Maybe there are other surprises.) > > patch to add global Suexec On/Off flag just posted for comments; if > there's nothing inherently problematic about it, perhaps we can get it > into future httpd 2.4 as well as httpd 2.2.next Future httpd 2.4 now has the Suexec directive, and a patch has been proposed for 2.2.next.
Re: Re: Anyone interested in a patch to mod_fcgid(with pay)
Yes, split process control from mod_fcgid, merge proxy_fcgi(with load balance) and mod_fcgid(with authXX support) is a good idea, admins can use httpd as process manager, or 3rd party process managers as they like. But don't just make a patch to make mod_fcgid support TCP/IP, it's ugly... > > > Hi, guys > >A company need a "TCP/IP patch of mod_fcgid or alternative", and > > will pay for it, anyone interested? I really like to take it but I > > don't have too much time... Anyone interested please reply to me and > > I will forward the email address of them. > > > > ... > > Neti only listens on TCP/IP socket, it assumes both an authorizer > > role and a responder role in the Fast CGI request. Here's the 3 > > candidate Apache modules to interface Neti: > > ... > > > > 2. Mod_proxy_fcgi: this module supports TCP socket, it can connect to > > Neti, but it doesn't support authorizer role. So in the first FCGI > > request, it forwards the request to Neti as a responder instead of an > > authorizer, Neti cannot simply let it through without properly > > authorizing it first, thus the request fails; > > > > 3. Mod_fcgid: this module supports authorizer role while doesn't > > support TCP connection. We cannot confirm its authorizer role since > > it doesn't even connect to Neti due to lack of TCP; > > > > So our choice is between either adding authorizer role to > > mod_proxy_fcgi or adding TCP/IP to mod_fcgid. > > > > We’re really willing to pay to have this project done, I mean either > > adding proxy to mod_fcgid or adding authorizer to mod_proxy_fcgi. Are > > you willing to work on this with reward or do you know anyone else > > who’s interested in doing so with pay, for example, author of > > mod_proxy_fcgi? (I cannot find his name) > > No cycles myself at this instant, but it seems overtime to break apart > the mod_fcgid process-control so that it can then stack on top of a > single mod_proxy_fcgi communications pipe, dispatched through different > fcgi-stream methods (including child process stdio), including the > various authn/authz roles. It would take more time to refactor it in > this way, but would get rid of any discrepancies between proxy_fcgi > and fcgid and serve as a good excuse to draw the remaining mod_fcgid > development back into trunk/, now that fcgid is generally sufficient > for 2.2 users. > > >
FYI... Planning to T&R mod_fcgid 2.3.8 in 7-10 days
-- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files
On Fri, Sep 20, 2013 at 4:31 PM, Benjamin Coddington wrote: > Hello everyone, > > We're looking at moving our shared hosting execution behind mod_fcgid and > suexec, but we need to continue to allow our users .htaccess 'Files' > overrides. The current mod_fcgid allows users to execute arbitrary > commands by configuring the FcgidAccessChecker, FcgidAuthenticator, > FcgidAuthorizer, and FcgidWrapper directives within .htaccess files. > > - https://issues.apache.org/bugzilla/show_bug.cgi?id=49220 > > I've approached a fix by creating a directive that would disable the > application of those directives within .htaccess files if set; that patch > has been submitted to the httpd bug 49220. > > You might shrewdly wonder "how can this matter - this is cgi after all, > we're just going to try to exec the resulting file!", but we're able to get > away from that by disabling ExecCGI globally and setting it per-request in > separate module which also ensures the request is mapped to our specific > FcgidWrapper. > > I see mod_fcgid 2.3.8 is closing in a few days; any chance to sneak this > in? Thanks for your time and consideration. > > Ben Unless someone else speaks up, I'll spend some time on it. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files
On Fri, Sep 20, 2013 at 4:31 PM, Benjamin Coddington wrote: > Hello everyone, > > We're looking at moving our shared hosting execution behind mod_fcgid and > suexec, but we need to continue to allow our users .htaccess 'Files' > overrides. The current mod_fcgid allows users to execute arbitrary > commands by configuring the FcgidAccessChecker, FcgidAuthenticator, > FcgidAuthorizer, and FcgidWrapper directives within .htaccess files. > > - https://issues.apache.org/bugzilla/show_bug.cgi?id=49220 > > I've approached a fix by creating a directive that would disable the > application of those directives within .htaccess files if set; that patch > has been submitted to the httpd bug 49220. > > You might shrewdly wonder "how can this matter - this is cgi after all, > we're just going to try to exec the resulting file!", but we're able to get > away from that by disabling ExecCGI globally and setting it per-request in > separate module which also ensures the request is mapped to our specific > FcgidWrapper. > > I see mod_fcgid 2.3.8 is closing in a few days; any chance to sneak this > in? Thanks for your time and consideration. > > Ben I'd like to see this aligned with 2.4's AllowOverrideList as much as practical, but AllowOverrideList is more flexible and I haven't yet looked at what changes to the patch would be necessary. The feature should be disabled when building for 2.4/trunk since those server versions already have an appropriate feature. It would be nice if the only change when moving between server versions is "FcgidAllowOverrideList"<->"AllowOverrideList". I'll look more in the next day. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files
On Sep 27, 2013, at 8:41 AM, Jeff Trawick wrote: > On Fri, Sep 20, 2013 at 4:31 PM, Benjamin Coddington wrote: > >> Hello everyone, >> >> We're looking at moving our shared hosting execution behind mod_fcgid and >> suexec, but we need to continue to allow our users .htaccess 'Files' >> overrides. The current mod_fcgid allows users to execute arbitrary >> commands by configuring the FcgidAccessChecker, FcgidAuthenticator, >> FcgidAuthorizer, and FcgidWrapper directives within .htaccess files. >> >> - https://issues.apache.org/bugzilla/show_bug.cgi?id=49220 >> >> I've approached a fix by creating a directive that would disable the >> application of those directives within .htaccess files if set; that patch >> has been submitted to the httpd bug 49220. >> >> You might shrewdly wonder "how can this matter - this is cgi after all, >> we're just going to try to exec the resulting file!", but we're able to get >> away from that by disabling ExecCGI globally and setting it per-request in >> separate module which also ensures the request is mapped to our specific >> FcgidWrapper. >> >> I see mod_fcgid 2.3.8 is closing in a few days; any chance to sneak this >> in? Thanks for your time and consideration. >> >> Ben > > > I'd like to see this aligned with 2.4's AllowOverrideList as much as > practical, but AllowOverrideList is more flexible and I haven't yet looked > at what changes to the patch would be necessary. The feature should be > disabled when building for 2.4/trunk since those server versions already > have an appropriate feature. It would be nice if the only change when > moving between server versions is > "FcgidAllowOverrideList"<->"AllowOverrideList". After your comments, I've looked closer at using AllowOverrideList to accomplish the same thing in configuration alone. I realized that when I initially tested this I had overlooked an 'AllowOverride FileInfo' in my config. So, while this approach may help the listed issue, it's not something we require on 2.4. It would be nice to have the inverse of AllowOverrideList (RestrictOverrideList?) that would explicitly deny directives allowed by the AllowOverride groups, since I'll now need to generate a large number of AllowOverrideList configurations in order to implement this across our hosting - which requires I walk our modules to find all the directives in FileInfo and explicitly allow them to disable these mod_fcgid directives. Ben
Re: [PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files
On Sep 27, 2013, at 1:50 PM, Benjamin Coddington wrote: > since I'll now need to generate a large number of > AllowOverrideList configurations in order to implement this across our > hosting - which requires I walk our modules to find all the directives in > FileInfo and explicitly allow them to disable these mod_fcgid directives. Or... just use this: httpd -L | grep -B3 FileInfo | grep -B2 .htaccess | egrep '^\w' Ben
Re: [PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files
On Fri, Sep 27, 2013 at 1:56 PM, Benjamin Coddington wrote: > On Sep 27, 2013, at 1:50 PM, Benjamin Coddington wrote: > > > since I'll now need to generate a large number of > > AllowOverrideList configurations in order to implement this across our > > hosting - which requires I walk our modules to find all the directives in > > FileInfo and explicitly allow them to disable these mod_fcgid directives. > > Or... just use this: > > httpd -L | grep -B3 FileInfo | grep -B2 .htaccess | egrep '^\w' > > Ben > As you have a solution with httpd 2.4.x, I won't think any more about this for fcgid 2.3.next. (And as time goes on it is less useful to others anyway.)
Re: svn commit: r815611 - in /httpd/site/trunk/docs/mod_fcgid: index.en.html index.html
On 16 Sep 2009, at 06:38, wr...@apache.org wrote: Author: wrowe Date: Wed Sep 16 05:38:09 2009 New Revision: 815611 URL: http://svn.apache.org/viewvc?rev=815611&view=rev Log: Generated new content Ouch! What is generating new content in "transitional" HTML, incorporating a bunch of crap that was deprecated as long ago as 1997? I know we have some legacy stuff, but our /docs/2.0/ and up have been an example of consistently Good Practice. It would be better to avoid a backwards step in importing new modules. -- Nick Kew
[PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
This has the potential for breaking existing configs by forcing the admin to
remove some ignored directives they've coded in a vhost.
The affected directives are BusyScanInterval, DefaultMaxClassProcessCount,
DefaultMinProcessCount, ErrorScanInterval, IdleScanInterval, IdleTimeout,
MaxProcessCount, PHP_Fix_Pathinfo_Enable, ProcessLifetime, SharedmemPath,
SocketPath, SpawnScore, SpawnScoreUpLimit, TerminationScore, TimeScore, and
ZombieScanInterval.
I suppose that a couple of these might have seemed to the administrator to
be more flexible than global-only, though it wouldn't have changed the
behavior when they added any of these to a vhost.
Please object now if you want to allow affected existing configurations to
continue to work. We can probably change the hard failure to a warning.
(A case where I might want to issue a warning for an ignored directive is
with IPCConnectTimeout on Unix; it is ignored there, but it has entered the
web wisdom as something that can help certain problems regardless of
platform. But that is independent of this patch.)
Index: fcgid_conf.c
===
--- fcgid_conf.c(revision 815491)
+++ fcgid_conf.c(working copy)
@@ -161,6 +161,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->idle_timeout = atol(arg);
return NULL;
}
@@ -178,6 +184,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->idle_scan_interval = atol(arg);
return NULL;
}
@@ -211,6 +223,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->busy_scan_interval = atol(arg);
return NULL;
}
@@ -229,6 +247,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->proc_lifetime = atol(arg);
return NULL;
}
@@ -246,6 +270,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->error_scan_interval = atol(arg);
return NULL;
}
@@ -264,6 +294,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->zombie_scan_interval = atol(arg);
return NULL;
}
@@ -281,6 +317,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->sockname_prefix = ap_server_root_relative(cmd->pool, arg);
if (!config->sockname_prefix)
return "Invalid socket path";
@@ -300,6 +342,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->shmname_path = ap_server_root_relative(cmd->pool, arg);
if (!config->shmname_path)
return "Invalid shmname path";
@@ -320,6 +368,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->spawnscore_uplimit = atol(arg);
return NULL;
}
@@ -372,6 +426,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+return err;
+}
+
config->spawn_score = atol(arg);
return NULL;
}
@@ -388,6 +448,12 @@
server_rec *s = cmd->server;
fcgid_server_conf *config =
ap_get_module_config(s->module_config, &fcgid_module);
+const char *err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
+
+if (err != NULL) {
+
Re: svn commit: r815611 - in /httpd/site/trunk/docs/mod_fcgid: index.en.html index.html
Nick Kew wrote: > > On 16 Sep 2009, at 06:38, wr...@apache.org wrote: > >> Author: wrowe >> Date: Wed Sep 16 05:38:09 2009 >> New Revision: 815611 >> >> URL: http://svn.apache.org/viewvc?rev=815611&view=rev >> Log: >> Generated new content > > Ouch! What is generating new content in "transitional" HTML, > incorporating a bunch of crap that was deprecated as long ago > as 1997? > > I know we have some legacy stuff, but our /docs/2.0/ and up > have been an example of consistently Good Practice. It would > be better to avoid a backwards step in importing new modules. Fairy nough. I simply borrowed the template from site/docs/mod_ftp/ (likely borrowed from mod_aspdotnet so long ago) so both need attention. Be my guest in updating these :) Bill
Re: Virtual Hosts & FCGI paths, was Re: [VOTE] release httpd mod_fcgid-2.3.1?
On 21.09.2009 09:11, Paul Querna wrote: > While, this is obviously a terrible thing for a general purpose > module, I would like to propose that we add a 'FCGIIgnoreVirtualHost' > configuration option, which would set the vhost field to a constant > value, so FCGI processes would be shared between virtual hosts. +1, I assume you meant this directive to be used per virtual host, not as a global setting? Or maybe even a 'FCGIGroup xyz' that lets you choose the string used instead of the virtual host name (if set). So you can combine according to your needs? On the positive side that would be more flexible, on the negative side you would always need to add an argument to the directive (or find a better directive name, that makes it more obvious, that with a missing argument it defines a default group). Regards, Rainer
Re: Virtual Hosts & FCGI paths, was Re: [VOTE] release httpd mod_fcgid-2.3.1?
On Mon, Sep 21, 2009 at 4:01 AM, Rainer Jung wrote: > On 21.09.2009 09:11, Paul Querna wrote: > > While, this is obviously a terrible thing for a general purpose > > module, I would like to propose that we add a 'FCGIIgnoreVirtualHost' > > configuration option, which would set the vhost field to a constant > > value, so FCGI processes would be shared between virtual hosts. > > +1, I assume you meant this directive to be used per virtual host, not > as a global setting? > > Or maybe even a 'FCGIGroup xyz' that lets you choose the string used > instead of the virtual host name (if set). So you can combine according > to your needs? On the positive side that would be more flexible, on the > negative side you would always need to add an argument to the directive > (or find a better directive name, that makes it more obvious, that with > a missing argument it defines a default group). > I like this in general. Having to supply an argument doesn't sound negative to me. It is probably inevitable, but the term "Group" here is potentially confused with the existing term "Class" (as used in DefaultMinClassProcessCount and DefaultMaxClassProcessCount).
Re: Virtual Hosts & FCGI paths, was Re: [VOTE] release httpd mod_fcgid-2.3.1?
On 21.09.2009 09:11, Paul Querna wrote: > (Sidenote: This virtualhost code is *only* present in the unix process > manager, which means there is a separate bug/issue in the win32 > process manager code) I compared the two spawn functions and made them more consistent in r817237 (both now using the server_hostname as virtualhost. Regards, Rainer
Re: Virtual Hosts & FCGI paths, was Re: [VOTE] release httpd mod_fcgid-2.3.1?
On 21.09.2009 13:41, Jeff Trawick wrote: > On Mon, Sep 21, 2009 at 4:01 AM, Rainer Jung <mailto:rainer.j...@kippdata.de>> wrote: > > On 21.09.2009 09:11, Paul Querna wrote: > > While, this is obviously a terrible thing for a general purpose > > module, I would like to propose that we add a 'FCGIIgnoreVirtualHost' > > configuration option, which would set the vhost field to a constant > > value, so FCGI processes would be shared between virtual hosts. > > +1, I assume you meant this directive to be used per virtual host, not > as a global setting? > > Or maybe even a 'FCGIGroup xyz' that lets you choose the string used > instead of the virtual host name (if set). So you can combine according > to your needs? On the positive side that would be more flexible, on the > negative side you would always need to add an argument to the directive > (or find a better directive name, that makes it more obvious, that with > a missing argument it defines a default group). > > > I like this in general. Having to supply an argument doesn't sound > negative to me. > > It is probably inevitable, but the term "Group" here is potentially > confused with the existing term "Class" (as used in > DefaultMinClassProcessCount and DefaultMaxClassProcessCount). I noticed an enty in our Chnagelog for mod_fcgid that actually dates back to August 2007 (r753578): 1. Patch from Gabriel Barazer, gabriel at oxeva.fr When setting multiple virtual hosts with the same SuexecUserGroup user and group, the process manager use the same process pool for both virtual hosts. This means if one virtual host has a DefaultInitEnv and the other has different values set, a fastcgi request from any of these virtual host can go to the same processes, which is inconsistent (a request from virtualhost a with DefaultInitEnv VAL "a", can go to a process spawned with virtualhost b with DefaultInitEnv VAL "b" set) So this reminds us, that if we want to share processes over the boundaries of VirtualHosts, we have a problem with all configuration which afftecs those processes and is possible per vhost. So in order to make the results predictable we need to look for clear semantics of such a process sharing. I currently do not have one. Regards, Rainer
Re: svn commit: r888840 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c
On Wed, Dec 9, 2009 at 10:36 AM, wrote: > Author: pqf > Date: Wed Dec 9 15:36:46 2009 > New Revision: 40 > > URL: http://svn.apache.org/viewvc?rev=40&view=rev > Log: > Bug fix, Bug 47873 - unreliable coordination between daemon and request > thread for BusyTimeout processing cool If you think users may have encountered a problem symptom from the original protocol, we can note it in CHANGES. I'm really not sure. Perhaps it would require the user to change some scan interval to a very large value. (When configured, scan intervals are typically set to a smaller value.) BTW, it is quite a challenge to review logic changes which contain unrelated style changes, so we don't do that. Use a separate commit with only style changes.
Re: svn commit: r888840 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c
Hi, I google a bit, it seems not much user encountered a "busy timeout" issue, and the old protocol should work in most cases, so I think it's no need to note in CHANGES? Next time I will separate commit logic changes and style changes :) Thanks -- From: "Jeff Trawick" Sent: Tuesday, December 15, 2009 10:49 PM To: Subject: Re: svn commit: r888840 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_pm_main.c > On Wed, Dec 9, 2009 at 10:36 AM, wrote: >> Author: pqf >> Date: Wed Dec 9 15:36:46 2009 >> New Revision: 40 >> >> URL: http://svn.apache.org/viewvc?rev=40&view=rev >> Log: >> Bug fix, Bug 47873 - unreliable coordination between daemon and request >> thread for BusyTimeout processing > > cool > > If you think users may have encountered a problem symptom from the > original protocol, we can note it in CHANGES. I'm really not sure. > Perhaps it would require the user to change some scan interval to a > very large value. (When configured, scan intervals are typically set > to a smaller value.) > > BTW, it is quite a challenge to review logic changes which contain > unrelated style changes, so we don't do that. Use a separate commit > with only style changes. >
tagging mod_fcgid-2.3.5 in the next day or so...anything in-progress?
Let me know if another day or two would help. (I'll look at a couple of issues myself to see if they have simple/safe solutions.)
[RMs plz review] very rough notes on how to tag/roll mod_fcgid
1. Tagging
a. pre-tag edits
fcgid_conf.h
MODFCGID_VERSION_{MAJOR,MINOR,SUBVER} should already be correct
MODFCGID_VERSION_DEV should be 1
change MODFCGID_VERSION_DEV to 0
CHANGES-FCGID - just make sure version at top is correct
STATUS-FCGID - add new " NEXTVERSION : in development line"
fix date of last tag
commit; use rev as XX below
b. tag
svn copy -rXX https://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk \
https://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
c. post-tag edits
fcgid_conf.h
increase MODFCGID_VERSION_SUBVER by 1 and set MODFCGID_VERSION_DEV
to 1
CHANGES-FCGID - add new "Changes with mod_fcgid NEXTVERSION" to the top
commit
2. Rolling
a. create appropriate roll.sh
start with /httpd/site/trunk/dist/tools/roll.sh
remove these lines from script:
find ... autom4te*
cd ... ./buildconf
find ... autom4te
touches of generated mod_ssl files
fix line that removes STATUS to remove STATUS-FCGID instead
keep the lines to remove manual source files
zap the "separate_deps" logic
commit to mod_fcgid/build/roll.sh after successful use
(need releasecheck.sh in same directory)
*or*
commit to /httpd/site/trunk/dist/tools/roll-fcgid.sh
b. export the source
umask 022
svn export
http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
\
mod_fcgid-MAJOR.MINOR.SUBVER
c. run the roll script
d. test signatures
3. make available
a. on people.apache.org:
umask 002
move tarballs and signature files to /www/httpd.apache.org/dev/dist
b. after rsync, announce testing to d...@httpd.a.o and test...@httpd.a.o
Re: svn commit: r1329187 - in /httpd/site/trunk/xdocs: download.xml mod_fcgid/index.en.xml
On Mon, Apr 23, 2012 at 7:21 AM, wrote: > Author: trawick > Date: Mon Apr 23 11:21:13 2012 > New Revision: 1329187 > > URL: http://svn.apache.org/viewvc?rev=1329187&view=rev > Log: > Announcing mod_fcgid 2.3.7... BTW Bill, any plans to create Windows binaries (2.2? 2.4?)? We would then restore+edit some text removed with this commit. > > Modified: > httpd/site/trunk/xdocs/download.xml > httpd/site/trunk/xdocs/mod_fcgid/index.en.xml > > Modified: httpd/site/trunk/xdocs/download.xml > URL: > http://svn.apache.org/viewvc/httpd/site/trunk/xdocs/download.xml?rev=1329187&r1=1329186&r2=1329187&view=diff > == > --- httpd/site/trunk/xdocs/download.xml [utf-8] (original) > +++ httpd/site/trunk/xdocs/download.xml [utf-8] Mon Apr 23 11:21:13 2012 > @@ -1,4 +1,4 @@ > - > + > > > Documentation Group > @@ -254,66 +254,43 @@ fixes a few potential security vulnerabi > > > Apache mod_fcgid FastCGI > module > -for Apache HTTP Server released as 2.3.6 > +for Apache HTTP Server released as 2.3.7 > > > The Apache Software Foundation and the Apache HTTP Server Project are > - pleased to announce the release of version 2.3.6 of mod_fcgid, a > + pleased to announce the release of version 2.3.7 of mod_fcgid, a > FastCGI implementation for Apache HTTP Server versions 2.0, 2.2, and > future 2.4. This version of mod_fcgid is a bug fix release. > > > - > - A fix is included for CVE-2010-3872, a potential vulnerability which > - can affect sites with untrusted FastCGI applications. > - > - > - > - Additionally, default configuration settings for request body handling > - have been changed to prevent large system resource use. Administrators > - of all versions of mod_fcgid are strongly cautioned to ensure that > - FcgidMaxRequestLen is configured appropriately. > - > - > For information about this module subproject, see the href="http://httpd.apache.org/mod_fcgid/";>mod_fcgid module project > page. > > > Unix Source as gzip with LF line endings: > - href="[preferred]/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.gz">mod_fcgid-2.3.6.tar.gz > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.gz.asc";>PGP] > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.gz.md5";>MD5] > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.gz.sha1";>SHA1] > + href="[preferred]/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.gz">mod_fcgid-2.3.7.tar.gz > +[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.gz.asc";>PGP] > +[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.gz.md5";>MD5] > +[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.gz.sha1";>SHA1] > > > Unix Source as bz2 with LF line endings: > - href="[preferred]/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.bz2">mod_fcgid-2.3.6.tar.bz2 > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.bz2.asc";>PGP] > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.bz2.md5";>MD5] > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6.tar.bz2.sha1";>SHA1] > + href="[preferred]/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.bz2">mod_fcgid-2.3.7.tar.bz2 > +[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.bz2.asc";>PGP] > +[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.bz2.md5";>MD5] > +[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.7.tar.bz2.sha1";>SHA1] > > > Win32, Netware or OS/2 Source with CR/LF line endings: > - - >mod_fcgid-2.3.6-crlf.zip > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6-crlf.zip.asc";>PGP] > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6-crlf.zip.md5";>MD5] > -[ href="http://www.apache.org/dist/httpd/mod_fcgid/mod_fcgid-2.3.6-crlf.zip.sha1";>SHA1] > - > - > -Win32 binary build (unzip over the installed Apache 2.2 directory): > - - >mod_fcgid-2.3.6-win32-x86.zip > -[ href="http://www.apache.org/dist/httpd/binaries/win32/mod_fcgid-2.3.6-win32-x86.zip.asc";>PGP] > -[ href="http://www.apache.org/dist/httpd/binaries/win32/mod_fcgid-2.3.6-win32-x86.zip.md5";>MD5] > -[ href="http://www.apache.org/dist/httpd/binaries/win32/mod_fcgid-2.3.6-win32-x86.zip.sha1";>SHA1] > + + >mod_fcgid-2.3.7-crlf.zip > +[ href="http://www.apac
Re: svn commit: r1329187 - in /httpd/site/trunk/xdocs: download.xml mod_fcgid/index.en.xml
On 4/23/2012 7:29 AM, Jeff Trawick wrote: > On Mon, Apr 23, 2012 at 7:21 AM, wrote: >> Author: trawick >> Date: Mon Apr 23 11:21:13 2012 >> New Revision: 1329187 >> >> URL: http://svn.apache.org/viewvc?rev=1329187&view=rev >> Log: >> Announcing mod_fcgid 2.3.7... > > BTW Bill, any plans to create Windows binaries (2.2? 2.4?)? We would > then restore+edit some text removed with this commit. I only just finished restoring my VC6 environment over the weekend, so yes, I can be doing that in the coming day or two. In the future, just whack the applicable (stale) sections with so I can get them back more trivially. 2.4, still involves wix and setting up packages that cleanly upgrade. It's been over a decade, so it's long past time. Plus the bug resolution. Looks like 2.4 will be right in step with 2.2, which I don't consider a bad thing, in terms of full and proper windows behaviors.
Re: FYI... Planning to T&R mod_fcgid 2.3.8 in 7-10 days
++1 On Sep 20, 2013, at 8:00 AM, Jeff Trawick wrote: > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/
Re: FYI... Planning to T&R mod_fcgid 2.3.8 in 7-10 days
+1 On 20 September 2013 14:00, Jeff Trawick wrote: > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/
Re: FYI... Planning to T&R mod_fcgid 2.3.8 in 7-10 days
+1 with many thanks, Chris. -- GPG Key ID: 088335A9 GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: [PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
Jeff Trawick wrote: > > Please object now if you want to allow affected existing configurations > to continue to work. We can probably change the hard failure to a warning. As this is a beta, let's just break the config, we should put something very clear in README about this.
Re: [PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
On 16.09.2009 17:18, Jeff Trawick wrote: > This has the potential for breaking existing configs by forcing the > admin to remove some ignored directives they've coded in a vhost. > > The affected directives are BusyScanInterval, > DefaultMaxClassProcessCount, DefaultMinProcessCount, ErrorScanInterval, > IdleScanInterval, IdleTimeout, MaxProcessCount, PHP_Fix_Pathinfo_Enable, > ProcessLifetime, SharedmemPath, SocketPath, SpawnScore, > SpawnScoreUpLimit, TerminationScore, TimeScore, and ZombieScanInterval. > > I suppose that a couple of these might have seemed to the administrator > to be more flexible than global-only, though it wouldn't have changed > the behavior when they added any of these to a vhost. Does it make sense to correctly merge some of them? I didn't check right now. Maybe some things are singletons, like the scanners, but others moght make sense per vhost, like e.g. the IdleTimeout or the scores. Consider e.g. when various vhosts use different wrappers.
Re: [PATCH/heads up] mod_fcgid: checking for global-only directives in a vhost
On Wed, Sep 16, 2009 at 11:42 AM, Rainer Jung wrote: > On 16.09.2009 17:18, Jeff Trawick wrote: > > This has the potential for breaking existing configs by forcing the > > admin to remove some ignored directives they've coded in a vhost. > > > > The affected directives are BusyScanInterval, > > DefaultMaxClassProcessCount, DefaultMinProcessCount, ErrorScanInterval, > > IdleScanInterval, IdleTimeout, MaxProcessCount, PHP_Fix_Pathinfo_Enable, > > ProcessLifetime, SharedmemPath, SocketPath, SpawnScore, > > SpawnScoreUpLimit, TerminationScore, TimeScore, and ZombieScanInterval. > > > > I suppose that a couple of these might have seemed to the administrator > > to be more flexible than global-only, though it wouldn't have changed > > the behavior when they added any of these to a vhost. > > Does it make sense to correctly merge some of them? I didn't check right > now. Maybe some things are singletons, like the scanners, but others > moght make sense per vhost, like e.g. the IdleTimeout or the scores. > Consider e.g. when various vhosts use different wrappers. > In the long term, maybe a few of them should support vhost-specific settings (PHP_Fix_Pathinfo_Enable, IdleTimeout, or ProcessLifetime). We'll see what people ask for (or who jumps in to implement ;) ). At the moment I'm more interested in fixing the settings that pretend to be merged and/or aren't picked up from the proper vhost.
Re: svn commit: r818234 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_conf.c fcgid_conf.h
On 09/23/2009 10:10 PM, traw...@apache.org wrote:
> Author: trawick
> Date: Wed Sep 23 20:10:02 2009
> New Revision: 818234
>
> URL: http://svn.apache.org/viewvc?rev=818234&view=rev
> Log:
> the request body size should be tracked and checked against
> apr_off_t, not size_t and int
>
> Modified:
> httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
> httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c
> httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.h
>
> Modified: httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c
> URL:
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c?rev=818234&r1=818233&r2=818234&view=diff
> ==
> --- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c (original)
> +++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c Wed Sep 23 20:10:02 2009
> @@ -354,13 +354,35 @@
> return NULL;
> }
>
> +static int strtoff(apr_off_t *val, const char *arg)
> +{
> +char *errp;
> +
> +#if APR_MAJOR_VERSION < 1
> +*val = (apr_off_t)strtol(arg, &errp, 10);
> +if (*errp) {
> +return 1;
> +}
> +#else
> +if (APR_SUCCESS != apr_strtoff(&conf->max_request_len, arg, &errp, 10)
> || *errp) {
Why not val here instead of &conf->max_request_len?
Copy and paste error ?
Regards
Rüdiger
Re: svn commit: r818234 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_bridge.c fcgid_conf.c fcgid_conf.h
On Wed, Sep 23, 2009 at 5:04 PM, Ruediger Pluem wrote:
>
>
> On 09/23/2009 10:10 PM, traw...@apache.org wrote:
> > Author: trawick
> > Date: Wed Sep 23 20:10:02 2009
> > New Revision: 818234
> >
> > URL: http://svn.apache.org/viewvc?rev=818234&view=rev
> > Log:
> > the request body size should be tracked and checked against
> > apr_off_t, not size_t and int
> >
> > Modified:
> > httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
> > httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c
> > httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.h
> >
>
> > Modified: httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c
> > URL:
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c?rev=818234&r1=818233&r2=818234&view=diff
> >
> ==
> > --- httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c (original)
> > +++ httpd/mod_fcgid/trunk/modules/fcgid/fcgid_conf.c Wed Sep 23 20:10:02
> 2009
> > @@ -354,13 +354,35 @@
> > return NULL;
> > }
> >
> > +static int strtoff(apr_off_t *val, const char *arg)
> > +{
> > +char *errp;
> > +
> > +#if APR_MAJOR_VERSION < 1
> > +*val = (apr_off_t)strtol(arg, &errp, 10);
> > +if (*errp) {
> > +return 1;
> > +}
> > +#else
> > +if (APR_SUCCESS != apr_strtoff(&conf->max_request_len, arg, &errp,
> 10) || *errp) {
>
> Why not val here instead of &conf->max_request_len?
> Copy and paste error ?
>
Yes, but worse yet I don't know what I was testing while experimenting with
the body size and the value of that directive (supposedly repeated for 2.0
and 2.2) :(
Thanks!
Re: tagging mod_fcgid-2.3.5 in the next day or so...anything in-progress?
On 1/20/2010 6:05 AM, Jeff Trawick wrote: > Let me know if another day or two would help. (I'll look at a couple > of issues myself to see if they have simple/safe solutions.) Actually, if you can tag this by tomorrow afternoon, I should be able to vote on it before the weekend, otherwise I won't be testing anything until next week. I have nothing to add in 2.3.5, my next ideas are novel enough to be destabilizing, and 2.3.5 should be the bandaid to 2.3.4 regressions.
Re: tagging mod_fcgid-2.3.5 in the next day or so...anything in-progress?
On Wed, Jan 20, 2010 at 12:41 PM, William A. Rowe Jr. wrote: > On 1/20/2010 6:05 AM, Jeff Trawick wrote: >> Let me know if another day or two would help. (I'll look at a couple >> of issues myself to see if they have simple/safe solutions.) > > Actually, if you can tag this by tomorrow afternoon, I should be able > to vote on it before the weekend, otherwise I won't be testing anything > until next week. will-do
Re: [RMs plz review] very rough notes on how to tag/roll mod_fcgid
Jeff Trawick wrote
> 1. Tagging
>
> a. pre-tag edits
>
>fcgid_conf.h
>
>MODFCGID_VERSION_{MAJOR,MINOR,SUBVER} should already be correct
>MODFCGID_VERSION_DEV should be 1
>change MODFCGID_VERSION_DEV to 0
>
>CHANGES-FCGID - just make sure version at top is correct
>
>STATUS-FCGID - add new " NEXTVERSION : in development line"
> fix date of last tag
>
>commit; use rev as XX below
>
>
I'd not commit the MODFCGID_VERSION_DEV earlier, rather commit the above
to trunk, then change the MODFCGID_VERSION_DEV and copy your WC to the tag
> b. tag
>
>svn copy -rXX https://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk \
> https://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
>
>
See above, copy tage from wc for release-only stuff
> c. post-tag edits
>
>fcgid_conf.h
>
>increase MODFCGID_VERSION_SUBVER by 1 and set MODFCGID_VERSION_DEV
>to 1
>
>
(no need to change MODFCGID_VERSION_DEV
Issac
Re: [RMs plz review] very rough notes on how to tag/roll mod_fcgid
On 1/21/2010 9:33 AM, Jeff Trawick wrote:
> 1. Tagging
>
> a. pre-tag edits
>
>fcgid_conf.h
>
>MODFCGID_VERSION_{MAJOR,MINOR,SUBVER} should already be correct
>MODFCGID_VERSION_DEV should be 1
>change MODFCGID_VERSION_DEV to 0
>
>CHANGES-FCGID - just make sure version at top is correct
>
>STATUS-FCGID - add new " NEXTVERSION : in development line"
> fix date of last tag
>
>commit; use rev as XX below
Looks right.
> b. tag
>
> svn copy -rXX https://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk \
> https://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
>
> c. post-tag edits
>
>fcgid_conf.h
>
>increase MODFCGID_VERSION_SUBVER by 1 and set MODFCGID_VERSION_DEV
>to 1
>
>CHANGES-FCGID - add new "Changes with mod_fcgid NEXTVERSION" to the top
>
>commit
Yup, it's that straightforward.
> 2. Rolling
>
> a. create appropriate roll.sh
>
>start with /httpd/site/trunk/dist/tools/roll.sh
>
>remove these lines from script:
> find ... autom4te*
> cd ... ./buildconf
> find ... autom4te
> touches of generated mod_ssl files
>
>fix line that removes STATUS to remove STATUS-FCGID instead
>
>keep the lines to remove manual source files
>
>zap the "separate_deps" logic
>
>commit to mod_fcgid/build/roll.sh after successful use
> (need releasecheck.sh in same directory)
>*or*
>commit to /httpd/site/trunk/dist/tools/roll-fcgid.sh
I saw roll.sh as being overly complex for mod_ftp/mod_fcgid work, since
the tarball is simply the contents of the repository. But I'm happy to
review that, and svn.a.o/httpd/site/trunk/dist/tools/roll-fcgid.sh sounds
like a good place to put it. I had included STATUS-FCGID in previous
source tarballs but have no objection to it going away as it does with
httpd tarballs.
We should probably move some of the "implements rfc" notes from STATUS
over to some README-FCGID document, instead, that doesn't disappear :)
> b. export the source
>
>umask 022
>svn export
> http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
> \
> mod_fcgid-MAJOR.MINOR.SUBVER
roll.sh should do the export, no? But the above is correct, and there is
a simple svn flag to export the same as '-crlf' flavor sources to be zipped.
> c. run the roll script
>
> d. test signatures
>
> 3. make available
This is entirely changed; there is a new repository for you to grab; check
out the following;
svn co https://dist.apache.org/repos/dist/dev/httpd/mod_fcgid fcgid-dev
svn co https://dist.apache.org/repos/dist/release/httpd/mod_fcgid fcgid-dist
Initially, svn add all the artifacts to the fcgid-dev repository for testing.
Once the vote has passed, you can literally do an svn mv between the two
locations to take it from httpd.a.o/dev/dist/ to www.a.o/dist/http/
Thanks to pquerna, svnpubsub magic will automagically update the files on the
site without further intervention.
https://svn.apache.org/repos/asf/httpd/site/trunk/ still needs to be touched
and then rebuilt and resynced. Depending on the visibility of release, you
might want to touch doap.rdf, xdocs/index.xml, and xdocs/download.xml to point
to the new release (and add a note of your key to download.xml).
Re: [RMs plz review] very rough notes on how to tag/roll mod_fcgid
On Thu, Jan 21, 2010 at 1:58 PM, William A. Rowe Jr. wrote: > On 1/21/2010 9:33 AM, Jeff Trawick wrote: >> 2. Rolling >> >> a. create appropriate roll.sh >> >> start with /httpd/site/trunk/dist/tools/roll.sh >> >> remove these lines from script: >> find ... autom4te* >> cd ... ./buildconf >> find ... autom4te >> touches of generated mod_ssl files >> >> fix line that removes STATUS to remove STATUS-FCGID instead >> >> keep the lines to remove manual source files >> >> zap the "separate_deps" logic >> >> commit to mod_fcgid/build/roll.sh after successful use >> (need releasecheck.sh in same directory) >> *or* >> commit to /httpd/site/trunk/dist/tools/roll-fcgid.sh > > I saw roll.sh as being overly complex for mod_ftp/mod_fcgid work, since > the tarball is simply the contents of the repository. But I'm happy to > review that, and svn.a.o/httpd/site/trunk/dist/tools/roll-fcgid.sh sounds > like a good place to put it. I had included STATUS-FCGID in previous > source tarballs but have no objection to it going away as it does with > httpd tarballs. > > We should probably move some of the "implements rfc" notes from STATUS > over to some README-FCGID document, instead, that doesn't disappear :) I kept STATUS-FCGID for now for consistency with previous tarball. >> b. export the source >> >> umask 022 >> svn export >> http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER >> \ >> mod_fcgid-MAJOR.MINOR.SUBVER > > roll.sh should do the export, no? But the above is correct, and there is > a simple svn flag to export the same as '-crlf' flavor sources to be zipped. release.sh does the export, but unfortunately it has even more httpd-specific logic I see that svn has "--native-eol CRLF" in some docs... works for me... that crlf export and zip -r was run on Linux... > >> c. run the roll script >> >> d. test signatures >> >> 3. make available > > This is entirely changed; there is a new repository for you to grab; check > out the following; > > svn co https://dist.apache.org/repos/dist/dev/httpd/mod_fcgid fcgid-dev ahh :) I had just gotten to that point... now to see which user/pass will make that checkout work :( > svn co https://dist.apache.org/repos/dist/release/httpd/mod_fcgid fcgid-dist > > Initially, svn add all the artifacts to the fcgid-dev repository for testing. > Once the vote has passed, you can literally do an svn mv between the two > locations to take it from httpd.a.o/dev/dist/ to www.a.o/dist/http/ > > Thanks to pquerna, svnpubsub magic will automagically update the files on the > site without further intervention. > > https://svn.apache.org/repos/asf/httpd/site/trunk/ still needs to be touched > and then rebuilt and resynced. Depending on the visibility of release, you > might want to touch doap.rdf, xdocs/index.xml, and xdocs/download.xml to point > to the new release (and add a note of your key to download.xml). speaking of key, the KEYS file at http://www.apache.org/dist/httpd/KEYS doesn't have the most recently committed contents... I guess we copy that from httpd/site/dist/KEYS to /dist/release/httpd/KEYS... thanks!
FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
... to correct a regression when used with httpd 2.0.x on some Unix-ish platforms.
heads up -- planning to T&R mod_fcgid 2.3.next in next 24 hours
Anything on the verge of being committed? (No worries over stuff that isn't quite ready; we can have another one soon-ish.)
Re: svn commit: r1037727 - in /httpd/mod_fcgid/trunk: CHANGES-FCGID modules/fcgid/fcgid_spawn_ctl.c
On Mon, Nov 22, 2010 at 9:08 AM, wrote: > Author: trawick > Date: Mon Nov 22 14:08:29 2010 > New Revision: 1037727 > > URL: http://svn.apache.org/viewvc?rev=1037727&view=rev > Log: > Fix regression in 2.3.6 which broke process controls when using vhost- > specific configuration. I'll post the patch today and also find some semi-automated way to test the process management controls in the future :(
mod_fcgid can kill all the services on the server via kill -15 -1
Hello,
There is a very interesting, and quite a rare bug in mod_fcgid. It is easy
to reproduce if you can cause fork to fail (which can be done with
CloudLinux -- if anyone wants to replicate it).
*Here is how it works: *
mod_fcgid tries to spawn a new process (proc_spawn_process in
fcgid_proc_unix.c), but fork returns -1.
More exactly fcgid_create_privileged_process function call returns error,
and fills in tmpproc.pid with -1 & tmpproc is assiged to procnode->proc_id).
Now, if at the same time service httpd restart is executed, function
kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
SIGKILL via proc_kill_force) to procnode->proc_id.pid
Yet, one procnode will be pointing to procnode->proc_id.pid, causing kill
-15 -1 (kill all).
The end results all services on the server failing, including SSH, apache,
syslogd, etc..
I guess the problem is really rare for most people. Also it is quite hard to
diagnose, as it is completely not clear where the signal came from, and it
took us some time to correlate them with apache restarts.. Yet due to our OS
being used by shared hosts (where httpd restart is common thing), and our
ability to limit memory available to processes on per virtual host bases
(which causes fork to fail once that virtual host reaches memory limit), we
see the issue quite often.
The solution is quite simple (not sure if it is the best / right solution),
in file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
should be changed to:
if (procnode->proc_id.pid != -1) {
rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
} else {
rv = APR_SUCCESS;
}
Similarly in proc_kill_force
rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
should be changed to:
if (procnode->proc_id.pid != -1) {
rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
} else {
rv = APR_SUCCESS;
}
Regards,
Igor Seletskiy
CEO @ Cloud Linux Inc
Re: svn commit: r1234437 - in /httpd/mod_fcgid/trunk: NOTICE-FCGID modules/fcgid/fcgid_conf.h
On Sat, Jan 21, 2012 at 5:49 PM, wrote: > Author: wrowe > Date: Sat Jan 21 22:49:25 2012 > New Revision: 1234437 > > URL: http://svn.apache.org/viewvc?rev=1234437&view=rev > Log: > Changes applied this year You don't need thanks from me, but "thanks" anyway for putting some time into this recently. I have enjoyed working in mod_fcgid quite a lot and deeply regret not helping whip it into better shape in recent times.
Re: svn commit: r1362317 - in /httpd/mod_fcgid/trunk: CHANGES-FCGID modules/fcgid/mod_fcgid.c
On Mon, Jul 16, 2012 at 8:02 PM, wrote:
> Author: chrisd
> Date: Tue Jul 17 00:02:26 2012
> New Revision: 1362317
>
> URL: http://svn.apache.org/viewvc?rev=1362317&view=rev
> Log:
> Merge access control hook function logic into a common base, with
> improved comments and logging, to reduce code duplication and simplify
> future maintenance.
>
> Modified:
> httpd/mod_fcgid/trunk/CHANGES-FCGID
> httpd/mod_fcgid/trunk/modules/fcgid/mod_fcgid.c
>
> Modified: httpd/mod_fcgid/trunk/CHANGES-FCGID
> URL:
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/CHANGES-FCGID?rev=1362317&r1=1362316&r2=1362317&view=diff
> ==
> --- httpd/mod_fcgid/trunk/CHANGES-FCGID [utf8] (original)
> +++ httpd/mod_fcgid/trunk/CHANGES-FCGID [utf8] Tue Jul 17 00:02:26 2012
> @@ -6,6 +6,10 @@ Changes with mod_fcgid 2.3.8
> treat Location headers returned by scripts as an error since
> redirections are not meaningful in this mode. [Chris Darroch]
>
> + *) Merge access control hook function logic into a common base, with
> + improved comments and logging, to reduce code duplication and
> + simplify future maintenance. [Chris Darroch]
Most of that is not user-visible stuff for CHANGES. (CHANGES would be
barely usable by users if every refactor or other code improvement was
described therein.)
"Improved logging for AAA handling" perhaps?
> +
> Changes with mod_fcgid 2.3.7
>
>*) Introduce FcgidWin32PreventOrphans directive on Windows to use OS
>
> Modified: httpd/mod_fcgid/trunk/modules/fcgid/mod_fcgid.c
> URL:
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/mod_fcgid.c?rev=1362317&r1=1362316&r2=1362317&view=diff
> ======
> --- httpd/mod_fcgid/trunk/modules/fcgid/mod_fcgid.c (original)
> +++ httpd/mod_fcgid/trunk/modules/fcgid/mod_fcgid.c Tue Jul 17 00:02:26 2012
> @@ -46,6 +46,12 @@ enum fcgid_procnode_type {
> FCGID_PROCNODE_TYPE_ERROR,
> };
>
> +enum fcgid_auth_check_mode {
> +FCGID_AUTH_CHECK_AUTHN,
> +FCGID_AUTH_CHECK_AUTHZ,
> +FCGID_AUTH_CHECK_ACCESS
> +};
> +
> /* Stolen from mod_cgi.c */
> /* KLUDGE --- for back-compatibility, we don't have to check ExecCGI
> * in ScriptAliased directories, which means we need to know if this
> @@ -477,107 +483,78 @@ static int mod_fcgid_modify_auth_header(
> return 1;
> }
>
> -static int mod_fcgid_authenticator(request_rec * r)
> +static int mod_fcgid_check_auth(request_rec *r,
> +enum fcgid_auth_check_mode auth_check_mode)
> {
> int res = 0;
> const char *password = NULL;
> apr_table_t *saved_subprocess_env = NULL;
> -fcgid_cmd_conf *authenticator_info;
> +fcgid_cmd_conf *auth_cmd_info = NULL;
> int authoritative;
> +const char *auth_role = NULL;
> +const char *role_log_msg = NULL;
> +const char *user_log_msg = "";
> +
> +/* Because we don't function as authn/z providers, integration with
> + * the standard httpd authn/z modules is somewhat problematic.
> + *
> + * With httpd 2.4 in particular, our hook functions may be
> + * circumvented by mod_authz_core's check_access_ex hook, unless
> + * Require directives specify that user-based authn/z is needed.
> + *
> + * Even then, APR_HOOK_MIDDLE may cause our authentication hook to be
> + * ordered after mod_auth_basic's check_authn hook, in which case it
> + * will be skipped unless AuthBasicAuthoritative is Off and no authn
> + * provider recognizes the user or outright denies the request.
> + *
> + * Also, when acting as an authenticator, we don't have a mechanism to
> + * set r->user based on the script response, so scripts can't implement
> + * a private authentication scheme; instead we use ap_get_basic_auth_pw()
> + * and only support Basic HTTP authentication.
> + *
> + * It is possible to act reliably as both authenticator and authorizer
> + * if mod_authn_core is loaded to support AuthType and AuthName, but
> + * mod_authz_core and mod_auth_basic are not loaded. However, in this
> + * case the Require directive is not available, which defeats many
> + * common configuration tropes.
> + */
>
> -authenticator_info = get_authenticator_info(r, &authoritative);
> +switch (auth_check_mode) {
> +case FCGID_AUTH_CHECK_AUTHN:
> +auth_cmd_info = get_authenticator_info(r, &authoritative);
> +auth_role = "AUTHENTICATOR";
> +ro
Re: svn commit: r1362317 - in /httpd/mod_fcgid/trunk: CHANGES-FCGID modules/fcgid/mod_fcgid.c
Jeff Trawick wrote: Most of that is not user-visible stuff for CHANGES. (CHANGES would be barely usable by users if every refactor or other code improvement was described therein.) "Improved logging for AAA handling" perhaps? Sure -- I just didn't want it to go unremarked, mostly in case there was some edge case I didn't test (although I tried to get 'em all) and it bit someone down the road. Please adjust as you see fit, or I can later on. Cheers, Chris. -- GPG Key ID: 088335A9 GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
Hi all, I'd like to propose a new configuration setting for "mod_fcgid". The source code changes to review follow: The whole patch compared to version 2.3.9: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split&name=maxnowait The whole patch as a single file: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified&name=maxnowait Every single commit compared to version 2.3.9: https://github.com/famzah/mod_fcgid/commits/maxnowait There should be no merge conflicts with the current "trunk" version 2.3.10. The motivation is that the current behavior to queue up new pending requests differs from the RLimitNPROC directive behavior. When there is a spike in the web hits, lots of Apache children get busy just waiting for up to 30+ seconds to get an idle FastCGI process. Thus we "waste" Apache children doing nothing while they could serve static content. This also puts unneeded memory pressure. Additionally, users today won't wait for a page to load, if it takes more than a few seconds, and we'd rather notify them that we are currently overloaded by sending them a 503 HTTP response immediately. Here is the documentation for the new directive: http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt Let me know what you think. Best regards. --Ivan
[mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root
Currently, starting httpd as non-root with mod_fcgid loaded fails unless User/Group are set to the active User/Group. Normally, httpd modules don't try to set ownership of objects to the specified User/Group unless starting as root. Thus, httpd.conf can contain reasonable User/Group settings for production use but still be suitable for use by Joe User. The affected code in fcgid_pm_unix.c is from the original revision ( http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487&view=markup ). Logic was added a couple of years ago ( http://svn.apache.org/viewvc?view=rev&revision=753553) to bypass the directory creation/chown if the directory already existed and had the correct ownership, to allow use with some SELinux policy. Comments/concerns? fcgid.patch Description: Binary data
[mod_fcgid] Problems installing 2.3.1 on SuSE 10.3 64bit due to missing mpm.h and mpm_default.h
I do not know whether i did something wrong but before a new release of mod_fcgid, i wanted to share my experience: I use Apache 2.2.13 on a OpenSUSE 10.3 distri and did download and extract mod_fcgid-2.3.1-beta.tar.gz to /usr/local/source/mod_fcgid-2.3.1 >From there i did APXS=/usr/sbin/apxs2 ./configure.apxs and following 'make', i got a gcc compiler error complaining about a missing mpm.h and mpm_default.h in /usr/include/apache2 I came around the problem by symlinking both files using :/usr/include/apache2 # ln -s ../apache2-prefork/mpm.h mpm.h :/usr/include/apache2 # ln -s ../apache2-prefork/mpm_default.h mpm_default.h and instead of 'make install' i just copied the resulting mod_fcgid.so as mod_fcgid.so-2.3.1 to /usr/lib64/apache2 followed by :/usr/lib64/apache2 # ln -s mod_fcgid.so-2.3.1 mod_fcgid.so after renaming the original file to mod_fcgid.so-2.2.org So, in the end i got it running (the problems i entered after using mod_fcgid with binary content are in another thread on this list). I just wonder whether i did something wrong or whether there is a 'flaw' in the Makefile which might causes this error with other people who may not be too experienced to find a solution themselves. Regards, Marcus
Re: FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
Jeff Trawick wrote: ... to correct a regression when used with httpd 2.0.x on some Unix-ish platforms. OK, noted. I very much hope to pack in some additional changes to the wrapper management code this week; time's still on my side at the moment. I spent some of Friday on it but what seemed like it might be a one- or two-liner revealed deeper problems that'll take a bigger fix than I'd initially hoped. I'll keep you posted as the week progresses if commits from me aren't forthcoming. Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
Jeff Trawick wrote:
... to correct a regression when used with httpd 2.0.x on some
Unix-ish platforms.
OK, I have a first cut at what I'm hoping to commit shortly, unless
anyone sees problems. Let me know if you want me to hold off until
you've cut another GA; otherwise I'll continue testing tomorrow and
look to commit ASAP.
Way back in the mists of time I added a one-liner to my collection
of mod_fcgid patches which simply changed the default share_group_id to
-1 for for responders which weren't invoked through a wrapper. This is
in handle_request(), like this:
shareid = wrapper_conf ? wrapper_conf->share_group_id : -1;
The intent is to avoid spawning the same process twice if it's used in both
responder and authorizer roles; auth configs always have a -1 share_group_id.
Anyway, looking into it more deeply this time around, I found that
there were a number of interconnected issues hidden in the wrapper code.
For one, it appears to be the case that when using FcgidWrapper in
.htaccess, there can be pool thread safety issues with multiple threads
trying to write into wrapper_id_hash to add any wrapper configs which turn
at runtime. And the wrapper_id_hash is per-process, so there's also
unnecessary duplication of FastCGI processes, because one httpd process's
list of wrapper IDs won't match another's for any IDs generated after
initial the config hooks finish.
I also found that because of the way wrapper IDs are handled, with
a global cur_id that's incremented for each new command line, and
then a per-command-line one that's incremented further from whatever
is assigned from cur_id whenever a command line appears in multiple
FcgidWrappers, that one can construct (admittedly pathological) cases
where the wrong FastCGI process is run. For example, this setup,
where wrapS is a symlink to wrap1:
FcgidWrapper "/path/to/fcgi/fcgi-bin/wrap1 1" .wrap11 virtual
FcgidWrapper "/path/to/fcgi/fcgi-bin/wrap1 1" .wrap12 virtual
FcgidWrapper "/path/to/fcgi/fcgi-bin/wrapS 2" .wrap21 virtual
In my testing, the .wrap12 and .wrap21 wrappers both ended up with
the same inode and deviceid (because of the symlink) and the same
share_group_id, even though they passed different arguments on their
command lines. So one of them ended up doing the wrong thing.
And there's also the original problem I set out to solve back
in 2007, plus various oddities about using AAA configs with wrappers
(which seems kinda supported, kinda not).
Anyway, this patchset below aims to fix those wrapper problems
in one, primarily by ditching the share_group_id and associated IDs,
and using the actual command line to decide if two FastCGI processes
are the same. In some quick late-evening testing that appeared to
work for me; no extra FastCGI processes were spawned even when using
multiple .htaccess configs.
I'll continue testing tomorrow, but I wanted to get some initial
feedback on (a) potential bugs and (b) whether I should aim to commit
before the 2.3.6 is rolled, or wait till after.
Chris.
Index: fcgid_proc_unix.c
===
--- fcgid_proc_unix.c (revision 905510)
+++ fcgid_proc_unix.c (working copy)
@@ -168,7 +168,7 @@
}
apr_status_t
-proc_spawn_process(char *lpszwapper, fcgid_proc_info * procinfo,
+proc_spawn_process(const char *lpszwapper, fcgid_proc_info * procinfo,
fcgid_procnode * procnode)
{
server_rec *main_server = procinfo->main_server;
Index: fcgid_proc_win.c
===
--- fcgid_proc_win.c(revision 905510)
+++ fcgid_proc_win.c(working copy)
@@ -58,7 +58,8 @@
return APR_SUCCESS;
}
-apr_status_t proc_spawn_process(char *wrapper_cmdline, fcgid_proc_info
*procinfo,
+apr_status_t proc_spawn_process(const char *wrapper_cmdline,
+fcgid_proc_info *procinfo,
fcgid_procnode *procnode)
{
HANDLE *finish_event, listen_handle;
Index: fcgid_pm_main.c
===
--- fcgid_pm_main.c (revision 905510)
+++ fcgid_pm_main.c (working copy)
@@ -19,6 +19,7 @@
#define CORE_PRIVATE
#include "httpd.h"
#include "http_config.h"
+#include "apr_strings.h"
#include "fcgid_pm.h"
#include "fcgid_pm_main.h"
@@ -492,7 +493,7 @@
/* Prepare to spawn */
procnode->deviceid = command->deviceid;
procnode->inode = command->inode;
-procnode->share_grp_id = command->share_grp_id;
+apr_cpystrn(procnode->cmdline, command->cmdline, _POSIX_PATH_MAX);
procnode->virtualhost = command->virtualhost;
procnode->uid = command->uid;
procnode->gid = command->gid;
@@ -537,7 +538,7 @@
/* Spawn the process now */
/* X
Re: FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
On Mon, Feb 1, 2010 at 11:54 PM, Chris Darroch wrote: > Jeff Trawick wrote: > >> ... to correct a regression when used with httpd 2.0.x on some >> Unix-ish platforms. > > OK, I have a first cut at what I'm hoping to commit shortly, unless > anyone sees problems. Let me know if you want me to hold off until > you've cut another GA; otherwise I'll continue testing tomorrow and > look to commit ASAP. Go ahead with the fix; I'll review in detail and test it once you commit your final version. (no paralysis; also, I'm slightly less anxious after another day has gone by without any fcgid-2.3.5+httpd-2.0+certain-platform complaints) BTW, I haven't seen (or recognized) a commit to allow both a FastCGI authorizer and a FastCGI handler for the same request. Have I missed something in this patch or in your most recent fix? I understood that your huge patch to fcgid-2.2 supported that. (no hurry, just wondering if I should enable a testcase)
Re: FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
Jeff: Go ahead with the fix; I'll review in detail and test it once you commit your final version. OK, I'll test more today first. Thanks. BTW, I haven't seen (or recognized) a commit to allow both a FastCGI authorizer and a FastCGI handler for the same request. Have I missed something in this patch or in your most recent fix? I understood that your huge patch to fcgid-2.2 supported that. (no hurry, just wondering if I should enable a testcase) Gettin' there. :-) My recollection is that there are three issues. First there was the issue I patched last week, which prevents AAA requests from generating large numbers of spurious FastCGI processes. Next, this patch I'm working on now includes the fix such that a FastCGI process that can be used in both AAA and responder roles only gets spawned once (because it's tracked by its common command line, not disjoint share_group_id values). There is still an issue which prevents a single request that uses the same FastCGI process for both AAA and response generation from re-using the same process. I'm just tackling one thing at a time, but my recollection here is that the process is acquired for use during AAA and then not released, so a second version gets spawned to handle the responder phase. According to my notes, those three things were all that I needed to fix to allow a single request to not only have FastCGI processes for AAA and for response generation, but in fact the same FastCGI process for both. But there may, of course, be other gotchas I haven't stumbled across -- let me know if you know of any. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
On Mon, Feb 1, 2010 at 10:59 AM, Jeff Trawick wrote: > ... to correct a regression when used with httpd 2.0.x on some > Unix-ish platforms. I haven't seen any other complaints (yet), so I'm in no big hurry to get out another release. I'll wait until we have a handful of solutions ready for real end-user problems, unless we see that this issue is affecting a number of people.
Re: FYI... tentatively planning to roll mod_fcgid again towards the end of the week...
Jeff: I haven't seen any other complaints (yet), so I'm in no big hurry to get out another release. I'll wait until we have a handful of solutions ready for real end-user problems, unless we see that this issue is affecting a number of people. OK, great. I'll try to move on to my next item re allowing auth and responders at the same time; I think this may have been where I introduced a bug last time (http://bugs.php.net/bug.php?id=48041) so I'll probably take a little extra time to review my work and test. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid can kill all the services on the server via kill -15 -1
Hi, all
Another question, does proc_wait_process() should update procnode->proc_id to 0
too? or else mod_fcgid may send a signal to another irrelevant process while
apache is shutting down? I don't follow up mod_fcgid for a while, I just took a
glance, maybe it's updated somewhere else?
By the way, procnode->proc_id is set to 0 while apache startup, so why not
update procnode->proc_id to 0 while fcgid_create_privileged_process() is fail?
And then check magic number 0 rather than both -1 and 0, in both
proc_kill_gracefully() and proc_kill_force().
Cheers.
Ryan
Hello,
There is a very interesting, and quite a rare bug in mod_fcgid. It is easy to
reproduce if you can cause fork to fail (which can be done with CloudLinux --
if anyone wants to replicate it).
Here is how it works:
mod_fcgid tries to spawn a new process (proc_spawn_process in
fcgid_proc_unix.c), but fork returns -1.
More exactly fcgid_create_privileged_process function call returns error, and
fills in tmpproc.pid with -1 & tmpproc is assiged to procnode->proc_id).
Now, if at the same time service httpd restart is executed, function
kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
SIGKILL via proc_kill_force) to procnode->proc_id.pid
Yet, one procnode will be pointing to procnode->proc_id.pid, causing kill -15
-1 (kill all).
The end results all services on the server failing, including SSH, apache,
syslogd, etc..
I guess the problem is really rare for most people. Also it is quite hard to
diagnose, as it is completely not clear where the signal came from, and it took
us some time to correlate them with apache restarts.. Yet due to our OS being
used by shared hosts (where httpd restart is common thing), and our ability to
limit memory available to processes on per virtual host bases (which causes
fork to fail once that virtual host reaches memory limit), we see the issue
quite often.
The solution is quite simple (not sure if it is the best / right solution), in
file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
should be changed to:
if (procnode->proc_id.pid != -1) {
rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
} else {
rv = APR_SUCCESS;
}
Similarly in proc_kill_force
rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
should be changed to:
if (procnode->proc_id.pid != -1) {
rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
} else {
rv = APR_SUCCESS;
}
Regards,
Igor Seletskiy
CEO @ Cloud Linux Inc
Re: mod_fcgid can kill all the services on the server via kill -15 -1
I like this idea better then just checking for pid == -1, though sending
TERM signal to 0 shouldn't be that damaging (if damaging at all).
Mostly because apachectl will run in different process group, so it will not
be killed, and will finish restarting apache.
And unless apache itself is embeded or started by some other software --
signal shouldn't kill anything but apache.
On Sun, Apr 17, 2011 at 9:58 PM, pqf wrote:
> Hi, all
> Another question, does proc_wait_process() should update procnode->proc_id
> to 0 too? or else mod_fcgid may send a signal to another irrelevant process
> while apache is shutting down? I don't follow up mod_fcgid for a while, I
> just took a glance, maybe it's updated somewhere else?
> By the way, procnode->proc_id is set to 0 while apache startup, so why not
> update procnode->proc_id to 0 while fcgid_create_privileged_process() is
> fail? And then check magic number 0 rather than both -1 and 0, in both
> proc_kill_gracefully() and proc_kill_force().
>
> Cheers.
> Ryan
>
>
>
> Hello,
>
> There is a very interesting, and quite a rare bug in mod_fcgid. It is easy
> to reproduce if you can cause fork to fail (which can be done with
> CloudLinux -- if anyone wants to replicate it).
>
> *Here is how it works: *
> mod_fcgid tries to spawn a new process (proc_spawn_process in
> fcgid_proc_unix.c), but fork returns -1.
> More exactly fcgid_create_privileged_process function call returns error,
> and fills in tmpproc.pid with -1 & tmpproc is assiged to procnode->proc_id).
>
> Now, if at the same time service httpd restart is executed, function
> kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
> through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
> SIGKILL via proc_kill_force) to procnode->proc_id.pid
> Yet, one procnode will be pointing to procnode->proc_id.pid, causing kill
> -15 -1 (kill all).
> The end results all services on the server failing, including SSH, apache,
> syslogd, etc..
>
> I guess the problem is really rare for most people. Also it is quite hard
> to diagnose, as it is completely not clear where the signal came from, and
> it took us some time to correlate them with apache restarts.. Yet due to our
> OS being used by shared hosts (where httpd restart is common thing), and our
> ability to limit memory available to processes on per virtual host bases
> (which causes fork to fail once that virtual host reaches memory limit), we
> see the issue quite often.
>
> The solution is quite simple (not sure if it is the best / right solution),
> in file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
>
> rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
>
> should be changed to:
>if (procnode->proc_id.pid != -1) {
> rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
>} else {
> rv = APR_SUCCESS;
>}
>
> Similarly in proc_kill_force
> rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
> should be changed to:
>if (procnode->proc_id.pid != -1) {
> rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
>} else {
> rv = APR_SUCCESS;
>}
>
> Regards,
> Igor Seletskiy
> CEO @ Cloud Linux Inc
>
>
>
Re: mod_fcgid can kill all the services on the server via kill -15 -1
Ryan,
I like this approach. Do you want us to prepare a patch against latest
version?
Also, we never committed to apache project. Would it be enough if we post a
patch here. Or what would be the process?
On Sun, Apr 17, 2011 at 9:58 PM, pqf wrote:
> Hi, all
> Another question, does proc_wait_process() should update procnode->proc_id
> to 0 too? or else mod_fcgid may send a signal to another irrelevant process
> while apache is shutting down? I don't follow up mod_fcgid for a while, I
> just took a glance, maybe it's updated somewhere else?
> By the way, procnode->proc_id is set to 0 while apache startup, so why not
> update procnode->proc_id to 0 while fcgid_create_privileged_process() is
> fail? And then check magic number 0 rather than both -1 and 0, in both
> proc_kill_gracefully() and proc_kill_force().
>
> Cheers.
> Ryan
>
>
>
> Hello,
>
> There is a very interesting, and quite a rare bug in mod_fcgid. It is easy
> to reproduce if you can cause fork to fail (which can be done with
> CloudLinux -- if anyone wants to replicate it).
>
> *Here is how it works: *
> mod_fcgid tries to spawn a new process (proc_spawn_process in
> fcgid_proc_unix.c), but fork returns -1.
> More exactly fcgid_create_privileged_process function call returns error,
> and fills in tmpproc.pid with -1 & tmpproc is assiged to procnode->proc_id).
>
> Now, if at the same time service httpd restart is executed, function
> kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
> through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
> SIGKILL via proc_kill_force) to procnode->proc_id.pid
> Yet, one procnode will be pointing to procnode->proc_id.pid, causing kill
> -15 -1 (kill all).
> The end results all services on the server failing, including SSH, apache,
> syslogd, etc..
>
> I guess the problem is really rare for most people. Also it is quite hard
> to diagnose, as it is completely not clear where the signal came from, and
> it took us some time to correlate them with apache restarts.. Yet due to our
> OS being used by shared hosts (where httpd restart is common thing), and our
> ability to limit memory available to processes on per virtual host bases
> (which causes fork to fail once that virtual host reaches memory limit), we
> see the issue quite often.
>
> The solution is quite simple (not sure if it is the best / right solution),
> in file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
>
> rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
>
> should be changed to:
>if (procnode->proc_id.pid != -1) {
> rv = apr_proc_kill(&(procnode->proc_id), SIGTERM);
>} else {
> rv = APR_SUCCESS;
>}
>
> Similarly in proc_kill_force
> rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
> should be changed to:
>if (procnode->proc_id.pid != -1) {
> rv = apr_proc_kill(&(procnode->proc_id), SIGKILL);
>} else {
> rv = APR_SUCCESS;
>}
>
> Regards,
> Igor Seletskiy
> CEO @ Cloud Linux Inc
>
>
>
Re: mod_fcgid can kill all the services on the server via kill -15 -1
On 5/3/2011 11:51 PM, pqf wrote: > Here is the new patch, anyone review it? I will commmit it if no one respond > :) +1, commit away
Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
Hello, I got no feedback. Am I posting this suggestion at the right mailing list? Best regards. --Ivan On 19.5.2016 г. 10:40 ч., Ivan Zahariev wrote: Hi all, I'd like to propose a new configuration setting for "mod_fcgid". The source code changes to review follow: * The whole patch compared to version 2.3.9: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split&name=maxnowait * The whole patch as a single file: https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified&name=maxnowait * Every single commit compared to version 2.3.9: https://github.com/famzah/mod_fcgid/commits/maxnowait * There should be no merge conflicts with the current "trunk" version 2.3.10. The motivation is that the current behavior to queue up new pending requests differs from the RLimitNPROC directive behavior. When there is a spike in the web hits, lots of Apache children get busy just waiting for up to 30+ seconds to get an idle FastCGI process. Thus we "waste" Apache children doing nothing while they could serve static content. This also puts unneeded memory pressure. Additionally, users today won't wait for a page to load, if it takes more than a few seconds, and we'd rather notify them that we are currently overloaded by sending them a 503 HTTP response immediately. Here is the documentation for the new directive: http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt Let me know what you think. Best regards. --Ivan
Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote: > Hello, > > I got no feedback. Am I posting this suggestion at the right mailing > list? Sorry, I see your original post marked for attention in my mail folder, but languishing hitherto unattended. Just now opened your link in a browser to take a look. There could be others who have done something similar. As a general reply to this question, yes, this is the best available mailinglist. The other place to post it would be as an enhancement request in bugzilla (issues.apache.org). The keyword "PatchAvailable" there may help by marking it as low-hanging fruit. -- Nick Kew
Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
Hi Nick, Thanks for the info. I've followed your instructions and submitted an enhancement request: https://bz.apache.org/bugzilla/show_bug.cgi?id=59656 Cheers. --Ivan On 31.5.2016 г. 13:45 ч., Nick Kew wrote: On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote: Hello, I got no feedback. Am I posting this suggestion at the right mailing list? Sorry, I see your original post marked for attention in my mail folder, but languishing hitherto unattended. Just now opened your link in a browser to take a look. There could be others who have done something similar. As a general reply to this question, yes, this is the best available mailinglist. The other place to post it would be as an enhancement request in bugzilla (issues.apache.org). The keyword "PatchAvailable" there may help by marking it as low-hanging fruit.
Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
Hello devs, It's been four months since I originally proposed this new feature in "mod_fcgid". During this time I've tested and deployed it on hundreds of busy production servers. It works as expected. If enabled, web visitors get an immediate response when FastCGI is overloaded, and no RAM is over-utilized. You can find all the information and a patch in the enhancement request at Bugzilla: https://bz.apache.org/bugzilla/show_bug.cgi?id=59656 Can we get this merged into "mod_fcgid"? Best regards. --Ivan On 2.6.2016 г. 11:57 ч., Ivan Zahariev wrote: Hi Nick, Thanks for the info. I've followed your instructions and submitted an enhancement request: https://bz.apache.org/bugzilla/show_bug.cgi?id=59656 Cheers. --Ivan On 31.5.2016 г. 13:45 ч., Nick Kew wrote: On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote: Hello, I got no feedback. Am I posting this suggestion at the right mailing list? Sorry, I see your original post marked for attention in my mail folder, but languishing hitherto unattended. Just now opened your link in a browser to take a look. There could be others who have done something similar. As a general reply to this question, yes, this is the best available mailinglist. The other place to post it would be as an enhancement request in bugzilla (issues.apache.org). The keyword "PatchAvailable" there may help by marking it as low-hanging fruit.
Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
On Mon, Sep 19, 2016 at 4:30 AM, Ivan Zahariev wrote: > Hello devs, > > It's been four months since I originally proposed this new feature in > "mod_fcgid". During this time I've tested and deployed it on hundreds of > busy production servers. It works as expected. If enabled, web visitors get > an immediate response when FastCGI is overloaded, and no RAM is > over-utilized. > > You can find all the information and a patch in the enhancement request at > Bugzilla: https://bz.apache.org/bugzilla/show_bug.cgi?id=59656 > > Can we get this merged into "mod_fcgid"? > > Best regards. > --Ivan Unfortunately there are not many reviewers for mod_fcgid. I tried to take as a relative laymen and had a few comments/questions: * a few C99 // comments were added and should be zapped * the assert looks funny -- no assert. maybe ap_debug_assert() so it blows up in maintainer builds only? * The new flag is merged, but cannot be unset? ** Probably need to make it look like an AP_INIT_FLAG * I couldn't follow the concept in the comments around max_process_count moving or being per-request. Is it maybe out of date? I think the current impl takes an existing global only and merges it with vhost server confs but it will always be a copy.
Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached
Hi, Thanks for the review. You can find my comments below in the reply. On 20.9.2016 г. 16:33 ч., Eric Covener wrote: Unfortunately there are not many reviewers for mod_fcgid. I tried to take as a relative laymen and had a few comments/questions: * a few C99 // comments were added and should be zapped Fixed. * the assert looks funny -- no assert. maybe ap_debug_assert() so it blows up in maintainer builds only? It's a paranoid check. If it ever blows the whistle, this will be in some very hard to reproduce case, and I don't expect that we catch this on a maintainer build. I made this an APLOG_CRIT message because a mismatch in the counts between proctable_count_all_nonfree_nodes() and "g_total_process" could make your FastCGI requests fail erroneously with an immediate 503 HTTP error. A System Administrator who could encounter this bug will appreciate the immediate APLOG_CRIT message in the "error_log". I don't insist this to remain like this and I will change it as you say, in order to comply with the usual development practices. Or we can give this function check a better name. * The new flag is merged, but cannot be unset? ** Probably need to make it look like an AP_INIT_FLAG Right. I've converted this to an AP_INIT_FLAG which makes more sense. I don't understand what you mean by "it cannot be unset". I'm merging it in the same way as other mod_fcgid config options. Please read below for more information regarding this matter. * I couldn't follow the concept in the comments around max_process_count moving or being per-request. Is it maybe out of date? I think the current impl takes an existing global only and merges it with vhost server confs but it will always be a copy. The original implementation allows you to set "max_process_count" in the GLOBAL_ONLY context. This is enforced by ap_check_cmd_context() in the AP_INIT_TAKE1() handler, because RSRC_CONF would otherwise allow us to define this config option also "per vhost". I've added the new variable "max_process_used_no_wait_enable" in the same way. The original implementation works well without further magic, because it really uses "max_process_count" in code which works with the "main_server" (global) context. Now I need to access the value of "max_process_count" inside a "request_rec" (per VirtualHost) variable. If one or more mod_fcgid directives are defined not only within the main server config, but also as additional settings in a VirtualHost context, then we need to merge "max_process_count", too. If we don't merge, the value of "max_process_count" returned by the "request_rec" variable will be the default init value (zero, in our case). Long story short -- you are right, this is a global only variable and it merges with vhost confs always as a copy of the global value. This is just a behind-the-scenes action and doesn't affect Apache administrators, since they can't define this variable in a vhost context anyway. I tried to summarize this as the comment ["global only" but we use its main_server value in a "request_rec"] but maybe someone can propose a better text. I've committed the source code changes and you can review them again. When we're satisfied with the changes, I'll test the final version on our server fleet. Best regards. --Ivan
