[mod_fcgid] How to share between vhosts (and extensions)
Sorry for the long mail, especially in case all is well-known. While looking for the right way to implement something like FCGIDGroup I stumbled about something a bit strange in mod_fcgid. When looking for an appropriate existing process to handle a request the following data is used by mod_fcgid: - inode inode num of the wrapper if one is used, of the request filename otherwise - deviceid device id of the wrapper if one is used, of the request filename otherwise - share_grp_id Always 0 if no wrapper is used, -1 for one of the auth wrappers, otherwise an incrementing id that is unique across each wrapper with the same path (but different vhosts or even only different extensions) ids between different paths can overlap - virtualhost: the pointer (!) to r-server-server_hostname - uid: retrieved via ap_run_get_suexec_identity - gid: retrieved via ap_run_get_suexec_identity If no process is found, a new one is created and carries the above data coming from the request (and wrapper) which ran when it was created. Going a bit through the history of mod_fcgid, it seems that share_grp_id was added to support a directive FCGIWrapperGroup (sic!). Later the directive was removed, and the id was automatically incremented to ensure separation. Again later there was a bug w.r.t. incomplete isolation of the default env between vhosts, so virtualhost was added, but seems only necessary for the non-wrapper case. It seems there's some potential for improvement concerning sharing of fastcgi applications. 1) Non-wrapper case The applications are given by the filenames the requests resolve to. So the most likely thing that could happen, is that someone wants to share the process pools for those between vhosts. I guess for this it would be enough to add FCGIDGroup. It would be optionally used once in vhosts to set a symbolic name, which will be used to seperate the pools between vhosts instead of the server_hostname. By choosing the same FCGIDGroup in several vhosts, one can share the process pool. 2) Wrapper case The wrapper is configured via its path name and the optional extension it applies to. At the moment independent pools are used for different vhosts, but also (!) for different extensions. So if we would add FCGIDGroup to a vhost, it would stop the extension separation. Another possibility would be, to apply FCGIDGroup only to the non-wrapper case and add some syntax to FCGIWrapper to allow expressing, which group it belongs to. Unfortunately that directive already has two optional arguments, one can be detected, because it starts with a dot, the other one is the fixed string virtual. The syntax might get ugly, if we need to safely distinguish three optional arguments Something like FCGIDWrapper wrapperpath [groupname] [.extension] [+flag ...] and the only flag implemented at the moment is virtual. Regards, Rainer
Re: [mod_fcgid] How to share between vhosts (and extensions)
On Wed, Sep 23, 2009 at 9:31 AM, Rainer Jung rainer.j...@kippdata.dewrote: When looking for an appropriate existing process to handle a request the following data is used by mod_fcgid: - inode inode num of the wrapper if one is used, of the request filename otherwise - deviceid device id of the wrapper if one is used, of the request filename otherwise - share_grp_id Always 0 if no wrapper is used, -1 for one of the auth wrappers, otherwise an incrementing id that is unique across each wrapper with the same path (but different vhosts or even only different extensions) ids between different paths can overlap - virtualhost: the pointer (!) to r-server-server_hostname I got educated on some of the ramifications of this while you were composing your e-mail ;) I just corrected some doc I wrote earlier. - uid: retrieved via ap_run_get_suexec_identity - gid: retrieved via ap_run_get_suexec_identity If no process is found, a new one is created and carries the above data coming from the request (and wrapper) which ran when it was created. Going a bit through the history of mod_fcgid, it seems that share_grp_id was added to support a directive FCGIWrapperGroup (sic!). Later the directive was removed, and the id was automatically incremented to ensure separation. Again later there was a bug w.r.t. incomplete isolation of the default env between vhosts, so virtualhost was added, but seems only necessary for the non-wrapper case. If two vhosts have the same server name, the default env can be shared, even if a wrapper is used. (I'll look at your e-mail in its entirely later. I'm awash in fcgid e-mails already, and the inbox directly connected to my bank account is overflowing :( )
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Hi Bill, William A. Rowe, Jr. schrieb: Then I'll roll tomorrow afternoon along with mod_fcgid. We have two ways to handle this; FTPOptions NoUTF8Feature, or something like; --- mod_ftp.c (revision 816386) +++ mod_ftp.c (working copy) @@ -86,12 +86,14 @@ ap_add_version_component(p, FTP_SERVER_STRING); +#if !defined(NETWARE) !defined(OS2) /* * Unless disabled, advertise that UTF8 filenames are preferred/permitted * RFC2640 never -requires- UTF8 names */ if (!(basefsc-options FTP_OPT_NO_UTF8_FEAT)) ftp_feat_advert(UTF8); +#endif /* Finalize ftp_cmd_help and ftp_cmd_feat messages */ ftp_cmd_finalize(p, ptemp); thoughts? I would prefer the 'FTPOptions NoUTF8Feature' thing because IIRC (its been 5,6 years back when we discussed that with Novell's core developers) we can now build an UTF8-enabled Apache, just its not what we do by default; so ifdef by platform is not right, at least not for NetWare; what about such in the config: IfModule mpm_netware_module FTPOptions NoUTF8Feature /IfModule BTW I've just tested 'FTPOptions NoUTF8Feature' - gave me no error during start, but still get UTF8 with feature list ... hopefully I have a bit time to investigate that further later - unless you beat me :) Gün.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: I would prefer the 'FTPOptions NoUTF8Feature' thing because IIRC (its been 5,6 years back when we discussed that with Novell's core developers) we can now build an UTF8-enabled Apache, just its not what we do by default; so ifdef by platform is not right, at least not for NetWare; what about such in the config: IfModule mpm_netware_module FTPOptions NoUTF8Feature /IfModule +1, please commit (# Notes would be helpful there) To confirm; if UTF8 characters are *invalid* and won't be accepted for path names, this feature should be set. If the server *can* name files in UTF8 this is the correct feature, even if the file names would appear 'odd' to the local user. This is why the feature is correct for Unix. BTW I've just tested 'FTPOptions NoUTF8Feature' - gave me no error during start, but still get UTF8 with feature list ... hopefully I have a bit time to investigate that further later - unless you beat me :) Inheritance issue, perhaps? I'll fix before rolling.
mod_fcgid: make install doesn't fully honour DESTDIR
Whilst the main software install is put under DESTDIR, the manual and eventually the config file when there is one, ignore the DESTDIR setting. This is a problem for downstream packagers, which is resolved for me by the attached patch. Cheers, Paul.--- mod_fcgid-2.3.1/Makefile.apxs 2009-09-04 20:11:49.0 +0100 +++ mod_fcgid-2.3.1/Makefile.apxs 2009-09-22 15:40:03.0 +0100 @@ -91,21 +91,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
mod_fcgid: copy-and-paste error in feature detection
The mod_fcgid build fails for me due to erroneously detecting sys/mutex.h when in fact it's not present. This appears to be due to a copy-and-paste error in build/Makefile.apxs, resolved by the attached patch. Cheers, Paul.--- mod_fcgid-2.3.1/build/Makefile.apxs 2009-08-27 12:33:51.0 +0100 +++ mod_fcgid-2.3.1/build/Makefile.apxs 2009-09-23 10:58:14.0 +0100 @@ -40,13 +40,13 @@ conftest_foofn: conftest_foofn.lo $(LINK) conftest_foofn.lo -conftest_sys_file_h: conftest_sys_mman_h.lo +conftest_sys_file_h: conftest_sys_file_h.lo @echo success $@ conftest_sys_mman_h: conftest_sys_mman_h.lo @echo success $@ -conftest_sys_mutex_h: conftest_sys_mman_h.lo +conftest_sys_mutex_h: conftest_sys_mutex_h.lo @echo success $@ conftest_sys_shm_h: conftest_sys_shm_h.lo
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Bill, William A. Rowe, Jr. schrieb: To confirm; if UTF8 characters are *invalid* and won't be accepted for path names, this feature should be set. If the server *can* name files in UTF8 this is the correct feature, even if the file names would appear 'odd' to the local user. This is why the feature is correct for Unix. hmm, then I probably add the directive but comment it out, and explain with a note; I've just tested and transfered from Linux a file with UTF-8 German Umlaute äöüß, and it was stored on the server, then retrieved same file from Win32, and that worked; however when I access the filesystem with the client then the filename is garbage, but still accessable. If I store a file with German Umlaute with the client then FileZilla is noz happy with it, and reports: Status: Invalid character sequence received, disabling UTF-8. Select UTF-8 option in site manager to force UTF-8. So if the user wants to serve files which were created via client then its required to disable the UTF8 feature I think ... Probably we can add a new directive for the future which can specify conversion like mod_char_lite; something like: FTPCharsetSourceEnc I think from this other systems can also profit, or? Gün.
Re: svn commit: r817830 - in /httpd/mod_fcgid/trunk: CHANGES-FCGID README-FCGID modules/fcgid/fcgid_conf.c modules/fcgid/fcgid_conf.h modules/fcgid/mod_fcgid.c
On Tue, Sep 22, 2009 at 5:10 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Sep 22, 2009 at 4:44 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: What state do you feel the module is in? When should we cut a beta to put the improvements-to-date into users hands? I think it is in a good state. A new tag tomorrow would be great. I'll test more between now and then. I did test more, and it still looks good.
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/domain.tld/conf/vhost.conf (in case of a subdomain ist could also be /srv/www/vhosts/domain.tld/subdomains/subdomain/conf/vhost.conf) and amending the respective httpd.include file (in /srv/www/vhosts/domain.tld/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 IfModule mod_fcgid.c 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: VirtualHost IP:80 ... Directory /srv/www/vhosts/domain.tld/httpdocs IfModule mod_perl.c Files ~ (\.pl$) SetHandler perl-script PerlHandler ModPerl::Registry Options ExecCGI allow from all PerlSendHeader On /Files /IfModule IfModule mod_python.c Files ~ (\.py$) SetHandler python-program PythonHandler mod_python.cgihandler /Files /IfModule IfModule mod_fcgid.c Files ~ (\.fcgi) SetHandler fcgid-script Options +FollowSymLinks +ExecCGI /Files /IfModule # IfModule mod_fcgid.c # Files ~ (\.php) # SetHandler fcgid-script # FCGIWrapper /usr/bin/php-cgi5 .php # Options +ExecCGI # allow from all # /Files # /IfModule Options -Includes -ExecCGI /Directory Include /srv/www/vhosts/domain.tld/conf/vhost.conf /VirtualHost so you could skip/delete the second IfModule mod_fcgid.c container from httpd.include. The included vhost.conf file then contains: --- Alias /phpfcgidpath/ /usr/bin/ Action php-fcgid /phpfcgidpath/php-cgi5 Location /phpfcgidpath/ SetHandler fcgid-script Options +ExecCGI /Location Files ~ (\.php) SetHandler php-fcgid FCGIWrapper /usr/bin/php-cgi5 .php Options +ExecCGI allow from all /Files --- 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: Files ~ (\.php) SetHandler php-fcgid FCGIWrapper /usr/bin/php-cgi5 .php Options +ExecCGI allow from all /Files to Files ~ (\.php) SetHandler fcgid-script FCGIWrapper /usr/bin/php-cgi5 .php Options +ExecCGI allow from all /Files (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
Re: mod_fcgid: copy-and-paste error in feature detection
On Wed, Sep 23, 2009 at 11:33 AM, Paul Howarth p...@city-fan.org wrote: The mod_fcgid build fails for me due to erroneously detecting sys/mutex.h when in fact it's not present. This appears to be due to a copy-and-paste error in build/Makefile.apxs, resolved by the attached patch. Cheers, Paul. Committed as r818185. Thanks!
Re: mod_fcgid: make install doesn't fully honour DESTDIR
On Wed, Sep 23, 2009 at 11:30 AM, Paul Howarth p...@city-fan.org wrote: Whilst the main software install is put under DESTDIR, the manual and eventually the config file when there is one, ignore the DESTDIR setting. This is a problem for downstream packagers, which is resolved for me by the attached patch. Thanks... committed as r818242.
mod_ftp needs the DESTDIR goodness in r818242
(AFAICT)
Re: Memory usage, core output filter, and apr_brigade_destroy
On 09/22/2009 09:19 PM, Stefan Fritsch wrote:
On Sunday 13 September 2009, Stefan Fritsch wrote:
On Sunday 13 September 2009, Ruediger Pluem wrote:
On 09/13/2009 01:11 PM, Stefan Fritsch wrote:
http://httpd.apache.org/docs/trunk/developer/output-filters.htm
l recommends to reuse bucket brigades and to not use
apr_brigade_destroy. However, both in 2.2 and in trunk, the
core output filter sometimes calls apr_brigade_destroy on
brigades that it has received down the chain from earlier
output filters. Is this not bound to cause problems since the
brigade's pool cleanup is then removed but the brigade is still
reused later on?
It could be. But the questions is if it is really reused later
on.
Since this is the recommended design for output filters, I am sure
it can happen.
I have attached two patches:
In the first, I change (hopefully) all places to not
apr_brigade_destroy brigades that have been passed down the filter
chain. Especially the core_output_filter change needs some review.
In the second, I have changed all occurences of apr_brigade_split to
apr_brigade_split_ex and I have made some more changes where bucket
brigades can be reused.
The test suite shows no regressions.
Index: server/protocol.c
===
--- server/protocol.c (Revision 818232)
+++ server/protocol.c (Arbeitskopie)
@@ -1239,6 +1239,7 @@
* least one bucket on to the next output filter
* for this request
*/
+apr_bucket_brigade *tmpbb;
};
/* This filter computes the content length, but it also computes the number
@@ -1259,6 +1260,8 @@
if (!ctx) {
f-ctx = ctx = apr_palloc(r-pool, sizeof(*ctx));
ctx-data_sent = 0;
+ctx-tmpbb = apr_brigade_create(r-connection-pool,
This should be r-pool instead. The lifetime of ctx itself is limited to r-pool
+r-connection-bucket_alloc);
}
@@ -1433,24 +1431,38 @@
if (f == NULL) {
/* our filter hasn't been added yet */
ctx = apr_pcalloc(r-pool, sizeof(*ctx));
+ctx-tmpbb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
+
ap_add_output_filter(OLD_WRITE, ctx, r, r-connection);
f = r-output_filters;
}
+return f;
+}
+
+static apr_status_t buffer_output(request_rec *r,
+ const char *str, apr_size_t len)
+{
+conn_rec *c = r-connection;
+ap_filter_t *f;
+old_write_filter_ctx *ctx;
+
+if (len == 0)
+return APR_SUCCESS;
+
+f = insert_old_write_filter(r);
+ctx = f-ctx;
+
/* if the first filter is not our buffering filter, then we have to
* deliver the content through the normal filter chain
*/
if (f != r-output_filters) {
-apr_bucket_brigade *bb = apr_brigade_create(r-pool, c-bucket_alloc);
apr_bucket *b = apr_bucket_transient_create(str, len, c-bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(bb, b);
+APR_BRIGADE_INSERT_TAIL(ctx-tmpbb, b);
-return ap_pass_brigade(r-output_filters, bb);
+return ap_pass_brigade(r-output_filters, ctx-tmpbb);
To be on the save side I think an apr_brigade_cleanup(ctx-tmpbb) is due
before doing the return, just in case a filter did not consume the buckets
properly.
}
@@ -1605,13 +1617,17 @@
AP_DECLARE(int) ap_rflush(request_rec *r)
{
conn_rec *c = r-connection;
-apr_bucket_brigade *bb;
apr_bucket *b;
+ap_filter_t *f;
+old_write_filter_ctx *ctx;
-bb = apr_brigade_create(r-pool, c-bucket_alloc);
+f = insert_old_write_filter(r);
+ctx = f-ctx;
+
b = apr_bucket_flush_create(c-bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(bb, b);
-if (ap_pass_brigade(r-output_filters, bb) != APR_SUCCESS)
+APR_BRIGADE_INSERT_TAIL(ctx-tmpbb, b);
+
+if (ap_pass_brigade(r-output_filters, ctx-tmpbb) != APR_SUCCESS)
Same as above: We should call apr_brigade_cleanup(ctx-tmpbb) to be on the save
side.
return -1;
return 0;
--- modules/http/chunk_filter.c (Revision 818232)
+++ modules/http/chunk_filter.c (Arbeitskopie)
@@ -49,11 +49,11 @@
#define ASCII_CRLF \015\012
#define ASCII_ZERO \060
conn_rec *c = f-r-connection;
-apr_bucket_brigade *more;
+apr_bucket_brigade *more, *tmp;
apr_bucket *e;
apr_status_t rv;
-for (more = NULL; b; b = more, more = NULL) {
+for (more = tmp = NULL; b; tmp = b, b = more, more = NULL) {
apr_off_t bytes = 0;
apr_bucket *eos = NULL;
apr_bucket *flush = NULL;
@@ -85,7 +85,8 @@
if (APR_BUCKET_IS_FLUSH(e)) {
flush = e;
if (e != APR_BRIGADE_LAST(b)) {
-more = apr_brigade_split(b, APR_BUCKET_NEXT(e));
+more = apr_brigade_split_ex(b, APR_BUCKET_NEXT(e), tmp);
+tmp = NULL;
}
break;
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=818234view=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=818234r1=818233r2=818234view=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 rpl...@apache.org 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=818234view=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=818234r1=818233r2=818234view=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: [VOTE] release httpd mod_ftp-0.9.5 beta?
Bill, William A. Rowe, Jr. schrieb: Guenter Knauf wrote: BTW I've just tested 'FTPOptions NoUTF8Feature' - gave me no error during start, but still get UTF8 with feature list ... hopefully I have a bit time to investigate that further later - unless you beat me :) Inheritance issue, perhaps? I'll fix before rolling. no - if I configure it outside the virtual host then it works - thanks to the docu which gave me the hint :) Gün.
Re: svn commit: r818287 - /httpd/httpd/branches/2.2.x/include/ap_mmn.h
On Wed, Sep 23, 2009 at 6:21 PM, minf...@apache.org wrote: Author: minfrin Date: Wed Sep 23 22:21:54 2009 New Revision: 818287 URL: http://svn.apache.org/viewvc?rev=818287view=rev Log: Bump minor mmn after addition of mod_proxy_scgi Why? The MMN is for programming interfaces. Does mod_proxy_scgi provide any?
Re: svn commit: r818287 - /httpd/httpd/branches/2.2.x/include/ap_mmn.h
Jeff Trawick wrote: Bump minor mmn after addition of mod_proxy_scgi Why? The MMN is for programming interfaces. Does mod_proxy_scgi provide any? Sorry, my bad - will revert. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
mod_fcgid and suexec problems
I initially opened a bug for this downstream (See Fedora #523903[1]), but the Fedora mod_fcgid maintainer Paul suggested I open up the discussion here. I was recently working on configuring some of my servers to use the worker MPM instead of prefork to be able to handle more concurrent connections without additional memory. Some of these servers use PHP, and it's well known that PHP is not very thread-safe so I started using mod_fcgid to handle PHP scripts. This worked great until I started testing PHP scripts in UserDirs, when suEXEC would then prevent the scripts from running since my FCGIWrapper is set to /usr/bin/php-cgi and that script isn't in the UserDir or owned by the user. After additional reading on suEXEC, I renamed the suexec binary to disable suEXEC, but this has the drawback that if the httpd package is updated, the binary will come back, too and re-enable suEXEC on the next httpd restart. I did some searching and found this post on the old mod_cgid lists where a user had the same problem and suggested (along with a patch) adding a configuration flag for mod_fcgid to disable suEXEC [2]. While a configuration flag like that would indeed fix my issue, I'm not convinced it's the right approach to this issue. Other possible solutions I had thought of: * Since Fedora (looks like RHEL does, too) compiles in suEXEC support and the recommended way to disable suEXEC support is to change the perms or delete the suexec binary, make suEXEC support a configuration/startup value and edit the startup scripts to do finagle the suexec binary before starting up Apache. * Introduce a global SuExecDisable setting that will disable SuExec in that configuration context. * Go with a mod_fcgid specific SuExec disable setting as mentioned earlier. Thoughts? -Dave [1] https://bugzilla.redhat.com/show_bug.cgi?id=523903 [2] http://www.mail-archive.com/mod-fcgid-us...@lists.sourceforge.net/msg00154.html
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: Bill, William A. Rowe, Jr. schrieb: To confirm; if UTF8 characters are *invalid* and won't be accepted for path names, this feature should be set. If the server *can* name files in UTF8 this is the correct feature, even if the file names would appear 'odd' to the local user. This is why the feature is correct for Unix. hmm, then I probably add the directive but comment it out, and explain with a note; I've just tested and transfered from Linux a file with UTF-8 German Umlaute äöüß, and it was stored on the server, then retrieved same file from Win32, and that worked; however when I access the filesystem with the client then the filename is garbage, but still accessable. If I store a file with German Umlaute with the client then FileZilla is noz happy with it, and reports: Status: Invalid character sequence received, disabling UTF-8. Select UTF-8 option in site manager to force UTF-8. Read the specs carefully. This is allowed. It is not necessary to disable UTF8 or stop using it, but simply treat a specific filename as an exception. Unix suffers this already, when several users of the same directories each use different local codepages. Windows is immune because all charsets ultimately are folded back into a unicode filesystem, but unix has no such concept. OS/X comes close. So if the user wants to serve files which were created via client then its required to disable the UTF8 feature I think ... Probably we can add a new directive for the future which can specify conversion like mod_char_lite; something like: FTPCharsetSourceEnc I think from this other systems can also profit, or? Absolutely not. Characters from 0x80 - 0xFF have absolutely no definition within FTP, they mean nothing. There is not so much as a mention of naming files with ISO-8859-1 or similar, it's an ASCII protocol. If you were to fix the netware case, the fix would be in APR; to treat all file naming with consistency and use UTF-8. But this is probably much more trouble than it's worth. Keep in mind some FTP clients don't even look to FEAT UTF8 to understand what filenames they are seeing, and presume their local native codepage. With no mechanism to determine the server and client side naming convention (other than FEAT UTF8) such filenames have always enjoyed inconsistency.
Re: [VOTE] release httpd mod_ftp-0.9.5 beta?
Guenter Knauf wrote: Bill, William A. Rowe, Jr. schrieb: Guenter Knauf wrote: BTW I've just tested 'FTPOptions NoUTF8Feature' - gave me no error during start, but still get UTF8 with feature list ... hopefully I have a bit time to investigate that further later - unless you beat me :) Inheritance issue, perhaps? I'll fix before rolling. no - if I configure it outside the virtual host then it works - thanks to the docu which gave me the hint :) This may change in the future as some HOST's might display different options (have spent some time reviewing the rfc draft). So far there has been no call to make FEAT vary by host or user.
Re: mod_ftp needs the DESTDIR goodness in r818242
Jeff Trawick wrote: (AFAICT) That was my guess as well, have that message open and looking at it now.
[vote] release httpd-2.2.14?
Hi all, The tarballs are (will soon be) at http://httpd.apache.org/dev/dist/. This release contains fixes for the following security issues: *) SECURITY: CVE-2009-2699 (cve.mitre.org) Fixed in APR 1.3.9. Faulty error handling in the Solaris pollset support (Event Port backend) which could trigger hangs in the prefork and event MPMs on that platform. PR 47645. [Jeff Trawick] *) SECURITY: CVE-2009-3095 (cve.mitre.org) mod_proxy_ftp: sanity check authn credentials. [Stefan Fritsch sf fritsch.de, Joe Orton] *) SECURITY: CVE-2009-3094 (cve.mitre.org) mod_proxy_ftp: NULL pointer dereference on error paths. [Stefan Fritsch sf fritsch.de, Joe Orton] +/-1 [ ] Release httpd-2.2.14 as GA Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r818315 - /httpd/site/trunk/dist/tools/release.sh
wr...@apache.org wrote: URL: http://svn.apache.org/viewvc?rev=818315view=rev Log: Validate r818275 by bundling apr 1.3.9 version. Should I recreate the binaries? (I've taken them offline so they don't sync). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [mod_fcgid] How to share between vhosts (and extensions)
FWIW, the Python specific hosting module called mod_wsgi for Apache implements named daemon process groups, with ability to control how WSGI applications are delegated to which process group. This includes being able to optionally have process group selected based on value of ENV value set by mod_rewrite. Various directives can optionally be used to limit which process groups can be delegated when using this. Anyway, not necessarily relevant but may still be of interest. Links to some of the documentation are: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIProcessGroup http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIRestrictProcess Graham 2009/9/23 Rainer Jung rainer.j...@kippdata.de: Sorry for the long mail, especially in case all is well-known. While looking for the right way to implement something like FCGIDGroup I stumbled about something a bit strange in mod_fcgid. When looking for an appropriate existing process to handle a request the following data is used by mod_fcgid: - inode inode num of the wrapper if one is used, of the request filename otherwise - deviceid device id of the wrapper if one is used, of the request filename otherwise - share_grp_id Always 0 if no wrapper is used, -1 for one of the auth wrappers, otherwise an incrementing id that is unique across each wrapper with the same path (but different vhosts or even only different extensions) ids between different paths can overlap - virtualhost: the pointer (!) to r-server-server_hostname - uid: retrieved via ap_run_get_suexec_identity - gid: retrieved via ap_run_get_suexec_identity If no process is found, a new one is created and carries the above data coming from the request (and wrapper) which ran when it was created. Going a bit through the history of mod_fcgid, it seems that share_grp_id was added to support a directive FCGIWrapperGroup (sic!). Later the directive was removed, and the id was automatically incremented to ensure separation. Again later there was a bug w.r.t. incomplete isolation of the default env between vhosts, so virtualhost was added, but seems only necessary for the non-wrapper case. It seems there's some potential for improvement concerning sharing of fastcgi applications. 1) Non-wrapper case The applications are given by the filenames the requests resolve to. So the most likely thing that could happen, is that someone wants to share the process pools for those between vhosts. I guess for this it would be enough to add FCGIDGroup. It would be optionally used once in vhosts to set a symbolic name, which will be used to seperate the pools between vhosts instead of the server_hostname. By choosing the same FCGIDGroup in several vhosts, one can share the process pool. 2) Wrapper case The wrapper is configured via its path name and the optional extension it applies to. At the moment independent pools are used for different vhosts, but also (!) for different extensions. So if we would add FCGIDGroup to a vhost, it would stop the extension separation. Another possibility would be, to apply FCGIDGroup only to the non-wrapper case and add some syntax to FCGIWrapper to allow expressing, which group it belongs to. Unfortunately that directive already has two optional arguments, one can be detected, because it starts with a dot, the other one is the fixed string virtual. The syntax might get ugly, if we need to safely distinguish three optional arguments Something like FCGIDWrapper wrapperpath [groupname] [.extension] [+flag ...] and the only flag implemented at the moment is virtual. Regards, Rainer
Re: [vote] release httpd-2.2.14?
Graham Leggett wrote: The tarballs are (will soon be) at http://httpd.apache.org/dev/dist/. Tarballs rolled with apr v1.3.9: SHA1(httpd-2.2.14.tar.bz2)= eacd04c87b489231ae708c84a77dc8e9ee176fd2 SHA1(httpd-2.2.14.tar.gz)= e6e20b3fc58a57a5116e036e31bf97d409db7cfa Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DO NOT REPLY [Bug 15866] cache MUST treat incomplete cached response as partial
On 23 Sep 2009, at 14:40, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=15866 --- Comment #6 from Dan Poirier poir...@pobox.com 2009-09-23 06:40:13 PDT --- Created an attachment (id=24306) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24306) Trunk patch to not cache responses whose length doesn't match the Content-length header Here's a trunk patch. It checks the length of the response after caching it, and if it doesn't match the Content-Length header, then drops the cache entry. Hey, you're a committer now! Any reason you didn't just commit? A patch will generally get more review in /trunk/ than in bugzilla if that's your concern. Or if you have particular issues you need to raise, a post to the dev list is in order. -- Nick Kew
Re: [vote] release httpd-2.2.14?
resend without attachments cause stupid mail server marked as virus ...
Hi Graham,
Graham Leggett schrieb:
The tarballs are (will soon be) at http://httpd.apache.org/dev/dist/.
This release contains fixes for the following security issues:
*) SECURITY: CVE-2009-2699 (cve.mitre.org)
Fixed in APR 1.3.9. Faulty error handling in the Solaris
pollset support (Event Port backend) which could trigger
hangs in the prefork and event MPMs on that platform.
PR 47645. [Jeff Trawick]
*) SECURITY: CVE-2009-3095 (cve.mitre.org)
mod_proxy_ftp: sanity check authn credentials.
[Stefan Fritsch sf fritsch.de, Joe Orton]
*) SECURITY: CVE-2009-3094 (cve.mitre.org)
mod_proxy_ftp: NULL pointer dereference on error paths.
[Stefan Fritsch sf fritsch.de, Joe Orton]
+/-1
[ ] Release httpd-2.2.14 as GA
the checksums are in wrong format. We need to commonly agree how to
generate checksum files. The documented format what the user expects is:
# cat httpd-2.2.14.tar.bz2.md5
a5226203aaf97e5b941c41a71c112704 *httpd-2.2.14.tar.bz2
# cat httpd-2.2.14.tar.bz2.sha1
eacd04c87b489231ae708c84a77dc8e9ee176fd2 *httpd-2.2.14.tar.bz2
I create these on Linux and Win32 with a shell / batch script:
#!/bin/sh
test -z $1 echo Usage: ${0##*/} file exit
md5sum -b ${1} ${1}.md5
sha1sum -b ${1} ${1}.sha1
@echo off
if (%1)==() goto END
md5sum -b %1 %1.md5
sha1sum -b %1 %1.sha1
:END
The huge benefit of this format is that the binaries can then be checked
with same tools (option -c).
Gün.
