Re: svn commit: r901578 - in /httpd/httpd/trunk: CHANGES modules/http/http_request.c modules/metadata/mod_headers.c server/protocol.c
On 1/21/2010 1:52 AM, Ruediger Pluem wrote: On 21.01.2010 08:20, wr...@apache.org wrote: Author: wrowe Date: Thu Jan 21 07:19:41 2010 New Revision: 901578 URL: http://svn.apache.org/viewvc?rev=901578view=rev Log: Correctly align the behavior of headers_in to be consistent with the treatment of headers_out, resolving PR 48359 by keeping subrequest scope changes out of the main request headers. This ensures that all requests-without-bodies behave as the requests-with-bodies code has. I think this is wrong. Think of the case where the subrequest does not change anything on headers_in. In this case the contents of headers_in of the request and the subrequest are the same (the subrequest has a copy of the requests table). Doing an apr_table_overlay would result in a table that has all key value pairs of the original headers_in doubled. Makes sense; reverted that bit.
Re: [mod_fcgid PATCH] catch errors from setuid()/seteuid()
On Wed, Jan 20, 2010 at 8:19 PM, pqf p...@mailtech.cn wrote: I man seteuid in my Linux box, there are two types of errors: ERRORS The seteuid() function shall fail if: EINVAL The value of the uid argument is invalid and is not supported by the implementation. EPERM The process does not have appropriate privileges and uid does not match the real group ID or the saved set-group- ID. If directly pass 0 in setuid(), EINVAL may not happend If this process is seteuid from root, EPERM may not happend so, I think the check is just a textbook logic check? yes, until somebody changes code or some other bug results in this being called in a different environment just call _exit(1) if it fail? two concerns with that minimal change: 1. seteuid() works once then fails n times now (at least on Solaris), so some extra logic is needed 2. even if these calls never fail, the presence of the exit() without a log message may cause somebody to lose a lot of time investigating a mysterious disappearance of the new process --/-- I'll punt on this until after 2.3.5 since I'd like to spend the time to watch it work on another platform or two. (suexec is not something I use more than once every ~3 years, so it is worth setting up in multiple environments.)
[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: [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. wr...@rowe-clan.net 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!
[VOTE] release mod_fcgid-2.3.5
mod_fcgid users, please try out mod_fcgid-2.3.5.tar.gz (or .tar.bz2) or the win32/netware suitable package mod_fcgid-2.3.5-crlf.zip from http://httpd.apache.org/dev/dist/mod_fcgid/ and cast your vote: [ ] -1 for release of 2.3.5 (regressed from 2.3.4) [ ] +1 to release as 2.3.5-GA Fixes and enhancements since our first GA release, 2.3.4: *) Stop using the unsuppressable notice log level for debug and informational messages. PR 48536. [Jeff Trawick] *) Respect DEFAULT_REL_RUNTIMEDIR for default values of FcgidIPCDir and FcgidProcessTableFile. [Jeff Trawick] *) Resolve fatal EDEADLK errors with threaded MPMs on Solaris. [Jeff Trawick] *) Display information about active processes in the server-status page. [Ryan Pan] *) Fix compatibility of httpd.conf-editing logic with non-GNU awk. PR 48067. [Hans Werner Strube strube physik3.gwdg.de] *) Fix startup errors creating shared memory in constrained systems, such as OS X in its default configuration. This is a regression since mod_fcgid 2.2. [Jeff Trawick] *) Recover from most Resource temporarily unavailable errors writing the request to the FastCGI application. These were common with large request bodies on Mac OS X and intermittent on Solaris. PR 48025. [Jeff Trawick] *) Fix a bug in fixconf.sed that resulted in a prefix of FcgidFcgid on the updated directives. [Dan Hulme dhulme gmail.com] *) Fix possible corruption or truncation of request bodies which exceed FcgidMaxRequestInMem. This is a regression since mod_fcgid 2.2, which effectively ignored FcgidMaxRequestInMem if larger than 8K. PR 48021. [Jeff Trawick] *) Fix handling of the request body when a FastCGI access checker/ authenticator/authorizer (AAA) was configured. The body wasn't available for the request handler. PR 47973. [Jeff Trawick, Barry Scott barry.scott onelan.co.uk] *) Fix handling of FcgidCmdOptions so that it can apply to wrapper scripts which were defined with command-line arguments on the FcgidWrapper directive. [Jeff Trawick]
[VOTE] Release httpd 2.3.5-alpha
Test tarballs for Apache httpd 2.3.5-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [ ] Release httpd-2.3.5 as Alpha Vote closes at 18:00 UTC on Monday January 25 2010. This includes a bundle of APR 1.4.2, and APR-Util 1.3.9. Thanks, Paul
Re: [VOTE] Release httpd 2.3.5-alpha
On Thu, Jan 21, 2010 at 2:34 PM, Paul Querna p...@querna.org wrote: Test tarballs for Apache httpd 2.3.5-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [ ] Release httpd-2.3.5 as Alpha Vote closes at 18:00 UTC on Monday January 25 2010. This includes a bundle of APR 1.4.2, and APR-Util 1.3.9. aurora.apache.org, aka www.apache.org has been upgraded. No problems so far!
Re: [mod_fcgid PATCH] catch errors from setuid()/seteuid()
Hi, Jeff Your concerns are right, +1 for your patch :) Thanks -- From: Jeff Trawick traw...@gmail.com Sent: Thursday, January 21, 2010 9:23 PM To: dev@httpd.apache.org Subject: Re: [mod_fcgid PATCH] catch errors from setuid()/seteuid() On Wed, Jan 20, 2010 at 8:19 PM, pqf p...@mailtech.cn wrote: I man seteuid in my Linux box, there are two types of errors: ERRORS The seteuid() function shall fail if: EINVAL The value of the uid argument is invalid and is not supported by the implementation. EPERM The process does not have appropriate privileges and uid does not match the real group ID or the saved set-group- ID. If directly pass 0 in setuid(), EINVAL may not happend If this process is seteuid from root, EPERM may not happend so, I think the check is just a textbook logic check? yes, until somebody changes code or some other bug results in this being called in a different environment just call _exit(1) if it fail? two concerns with that minimal change: 1. seteuid() works once then fails n times now (at least on Solaris), so some extra logic is needed 2. even if these calls never fail, the presence of the exit() without a log message may cause somebody to lose a lot of time investigating a mysterious disappearance of the new process --/-- I'll punt on this until after 2.3.5 since I'd like to spend the time to watch it work on another platform or two. (suexec is not something I use more than once every ~3 years, so it is worth setting up in multiple environments.)
