Re: HEAD broken?
On Mon, 13 May 2002, Justin Erenkrantz wrote: > Okay, I committed changes to both apr-config and apu-config so > that they will always print the .la file information. -- justin Thanks!! --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: HEAD broken?
On Mon, May 13, 2002 at 10:54:55PM -0400, Cliff Woolley wrote: > On Mon, 13 May 2002, Justin Erenkrantz wrote: > > > Hmm. We could modify apr-config to always print the la-file even > > if it doesn't exist yet. Can you try this? > > That fixed it. Okay, I committed changes to both apr-config and apu-config so that they will always print the .la file information. -- justin
Re: HEAD broken?
On Mon, 13 May 2002, Justin Erenkrantz wrote: > Hmm. We could modify apr-config to always print the la-file even > if it doesn't exist yet. Can you try this? That fixed it. Thanks, Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: HEAD broken?
On Mon, May 13, 2002 at 10:40:21PM -0400, Cliff Woolley wrote: > On Mon, 13 May 2002, Justin Erenkrantz wrote: > > > > Justin, is this related to your recent commits? > > > > I don't think so, but what does your link line say? It looks like > > apr isn't being linked in correctly. -- justin > > Aww crap, I see what's happening. Because of the way it's finding -lapr > now, it's finding the very old copy I have installed in /usr/local/lib and > using it in preference to the one I just built. That's why only *some* of > the APR symbols show up missing... it's just the ones that have been added > since I built that old copy in /usr/local/lib. Hmm. We could modify apr-config to always print the la-file even if it doesn't exist yet. Can you try this? Actually, I bet if you re-ran configure right now, apr-config would print the .la file since it *now* exists (so it won't do the -L.. -lapr construct). I was considering that only printing the LA_FILE only when it exists seems bogus. -- justin Index: apr-config.in === RCS file: /home/cvs/apr/apr-config.in,v retrieving revision 1.15 diff -u -r1.15 apr-config.in --- apr-config.in 1 Apr 2002 19:30:27 - 1.15 +++ apr-config.in 14 May 2002 02:44:56 - @@ -185,19 +185,10 @@ fi ;; --link-libtool) -if test -f "$LA_FILE"; then -flags="$flags $LA_FILE" -elif test "$location" = "installed"; then -### avoid using -L if libdir is a "standard" location like /usr/lib -flags="$flags -L$libdir -lapr" -else -flags="$flags -L$thisdir -lapr" -fi +flags="$flags $LA_FILE" ;; --apr-la-file) -if test -f "$LA_FILE"; then -flags="$flags $LA_FILE" -fi +flags="$flags $LA_FILE" ;; --apr-so-ext) echo "$APR_SO_EXT"
Re: HEAD broken?
On Mon, 13 May 2002, Justin Erenkrantz wrote: > > Justin, is this related to your recent commits? > > I don't think so, but what does your link line say? It looks like > apr isn't being linked in correctly. -- justin Aww crap, I see what's happening. Because of the way it's finding -lapr now, it's finding the very old copy I have installed in /usr/local/lib and using it in preference to the one I just built. That's why only *some* of the APR symbols show up missing... it's just the ones that have been added since I built that old copy in /usr/local/lib. Example: /bin/sh /root/apache/httpd-2.0/srclib/apr/libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread -DNO_DBM_REWRITEMAP-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -DAP_HAVE_DESIGNATED_INITIALIZER -I/root/apache/httpd-2.0/srclib/apr/include -I/root/apache/httpd-2.0/srclib/apr-util/include -I/usr/local/include -I. -I/root/apache/httpd-2.0/os/unix -I/root/apache/httpd-2.0/server/mpm/prefork -I/root/apache/httpd-2.0/modules/http -I/root/apache/httpd-2.0/modules/proxy -I/root/apache/httpd-2.0/include -I/usr/include/openssl -I/root/apache/httpd-2.0/modules/dav/main -export-dynamic -L/usr/local/lib -o htpasswd htpasswd.lo -L/usr/local/lib -lz -lssl -lcrypto /root/apache/httpd-2.0/srclib/pcre/libpcre.la -L/root/apache/httpd-2.0/srclib/apr-util -laprutil -lgdbm -ldb /usr/local/lib/libexpat.la -L/root/apache/httpd-2.0/srclib/apr -lapr -lm -lcrypt -lnsl -ldl --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: HEAD broken?
On Mon, May 13, 2002 at 10:28:01PM -0400, Cliff Woolley wrote: > > /root/apache/httpd-2.0/support/htpasswd.c:409: undefined reference to > `apr_app_initialize' > /root/apache/httpd-2.0/support/htpasswd.c:414: undefined reference to > `apr_pool_create_ex' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_pstrmemdup' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_allocator_free' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_time_exp_get' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_allocator_destroy' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_allocator_alloc' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_mmap_dup' > /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined > reference to `apr_allocator_create' > collect2: ld returned 1 exit status > make[2]: *** [htpasswd] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > > Justin, is this related to your recent commits? I don't think so, but what does your link line say? It looks like apr isn't being linked in correctly. -- justin
HEAD broken?
/root/apache/httpd-2.0/support/htpasswd.c:409: undefined reference to `apr_app_initialize' /root/apache/httpd-2.0/support/htpasswd.c:414: undefined reference to `apr_pool_create_ex' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_pstrmemdup' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_allocator_free' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_time_exp_get' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_allocator_destroy' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_allocator_alloc' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_mmap_dup' /root/apache/httpd-2.0/srclib/apr-util/.libs/libaprutil.so: undefined reference to `apr_allocator_create' collect2: ld returned 1 exit status make[2]: *** [htpasswd] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Justin, is this related to your recent commits? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/arch/win32 mod_isapi.c
Outch... thanks.
Fortunately, that isn't the final file. I had finished the entire effort,
so I was
attempting to break the changes into components that could be followed,
bit by bit. It took a full day to break this overhaul into manageable,
modular
changes, sorry I missed that.
Fortunately, subsequent changes drop out those issues entirely, which is
why the mistakes weren't on my radar as I incrementally built diffs of it all.
Bill
At 05:57 PM 5/13/2002, you wrote:
>On Mon, May 13, 2002 at 09:23:13PM -, [EMAIL PROTECTED] wrote:
> > wrowe 02/05/13 14:23:13
> >
> > Modified:modules/arch/win32 mod_isapi.c
> > Log:
> > Part two; nearly inconsequential - Made the log message prefix ISAPI:
> > (rather than ISAPI with no trailing colon) and normalized some
> variables
> > and static fn names to 'apache names' rather than MSisms.
>
>When you do a replace of names, I *highly* recommend checking them... :-)
>
> >...
> > @@ -135,65 +148,65 @@
> >long val;
> >
> >if (((val = strtol(arg, (char **) &scan, 10)) <= 0) || *scan)
> > -return "ISAPIReadAheadBuffer must be a legitimate value.";
> > +return "ISAPIread_ahead_buflen must be a legitimate value.";
>
>Whoops!
>
> >...
> >/*
> > - * Command handler for the ISAPIReadAheadBuffer directive, which is
> TAKE1
> > + * Command handler for the ISAPIread_ahead_buflen directive, which
> is TAKE1
>
>Dang...
>
> >...
> >else {
> > -return "ISAPILogNotSupported must be on or off";
> > +return "ISAPIlog_unsupported must be on or off";
>
>blarg...
>
>etc.
>
>Cheers,
>-g
>
>--
>Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-1.3/src/main http_main.c
On Mon, May 13, 2002 at 11:00:09PM -, [EMAIL PROTECTED] wrote:
> Index: http_main.c
> ===
> RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
> retrieving revision 1.580
> retrieving revision 1.581
> diff -u -r1.580 -r1.581
> --- http_main.c 22 Apr 2002 18:23:19 - 1.580
> +++ http_main.c 13 May 2002 23:00:07 - 1.581
> @@ -3374,19 +3377,24 @@
>!defined(BONE)
>/* Don't detach for MPE because child processes can't survive the death of
> the parent. */
> -if ((x = fork()) > 0)
> - exit(0);
> -else if (x == -1) {
> - perror("fork");
> - fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
> - exit(1);
> +if (do_detach) {
> +if ((x = fork()) > 0)
> +exit(0);
> +else if (x == -1) {
> +perror("fork");
> + fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
> + exit(1);
> +}
> +RAISE_SIGSTOP(DETACH);
>}
> -RAISE_SIGSTOP(DETACH);
>#endif
>#ifndef NO_SETSID
> -if ((pgrp = setsid()) == -1) {
> +if (pgrp = setsid()) == -1) {
Without compiling this, I'd guess that you're missing a (. This
portion should be reverted. -- justin
Re: Deamon tools
> the wrong pgrp later. So I think Aaron's right. Ok - committed - please check that it matches people their consensus :-). Dw
Re: cvs commit: httpd-2.0/modules/arch/win32 mod_isapi.c
On Mon, May 13, 2002 at 09:23:13PM -, [EMAIL PROTECTED] wrote:
> wrowe 02/05/13 14:23:13
>
> Modified:modules/arch/win32 mod_isapi.c
> Log:
> Part two; nearly inconsequential - Made the log message prefix ISAPI:
> (rather than ISAPI with no trailing colon) and normalized some variables
> and static fn names to 'apache names' rather than MSisms.
When you do a replace of names, I *highly* recommend checking them... :-)
>...
> @@ -135,65 +148,65 @@
>long val;
>
>if (((val = strtol(arg, (char **) &scan, 10)) <= 0) || *scan)
> -return "ISAPIReadAheadBuffer must be a legitimate value.";
> +return "ISAPIread_ahead_buflen must be a legitimate value.";
Whoops!
>...
>/*
> - * Command handler for the ISAPIReadAheadBuffer directive, which is TAKE1
> + * Command handler for the ISAPIread_ahead_buflen directive, which is TAKE1
Dang...
>...
>else {
> -return "ISAPILogNotSupported must be on or off";
> +return "ISAPIlog_unsupported must be on or off";
blarg...
etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Deamon tools
> What do you mean? At what point do we stop trying to detect errors > and let the daemon go on its merry way? Ideally once she says: [Mon May 13 14:39:24 2002] [notice] Apache/1.3.25-dev (Unix) configured -- resuming normal operations which if I recall correctly is the moment after which you can only get errors/permission faults which are to be triggered by request/runtime sort of things (unless the first flock() is a bit later). Dw
Re: Deamon tools
> Of course the real patch is to make the exit codes always reliable - even > when we fork and detach ;-) What do you mean? At what point do we stop trying to detect errors and let the daemon go on its merry way? -aaron
Re: Deamon tools
> As long as you still do the fork(2) decision before the setsid(2) call, > no. :) Of course the real patch is to make the exit codes always reliable - even when we fork and detach ;-) Dw
Re: Deamon tools
Aaron Bannert <[EMAIL PROTECTED]> writes:
> Now that I think about it a little more, we should probably always
> exit if setsid() fails.
That sounds good. The only instance I can see setsid(2) legitimately
failing other than OS resource exhaustion or something is when you
invoke httpd -F interactively under a shell with job control, and
well, if you need to do that, invoke a non-job control shell first.
> It might be useful to change the error message
> if no_detach is set ("setsid() failed probably because you aren't
> running under a process management tool like daemontools" vs "setsid()
> failed, unable to create new session"). Then we just do the fork fork()
> if !no_detach. Confused yet?
As long as you still do the fork(2) decision before the setsid(2) call,
no. :)
Re: Deamon tools
On Mon, 13 May 2002, Aaron Bannert wrote: > On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote: > > In that case I'd suggest we do > > > > if (setsid() fails) > > always log error > > exit(1) unless no_detach. > > should that be > exit(1) if no_detach > ? or do I have the logic backward? Yes - sorry.
Re: Deamon tools
> Note that I'm not sure if httpd 2.0 is this robust in handling > setsid(2), so if we're spending the time on this and it's considered > important for 1.3, someone should probably spend some time on making > 2.0 as robust. I improved the error detecting in 2.0 when originally adding Jos' patch there, and apr_proc_detach returns an error if setsid() or setpgrp() fails internally, but the error message may still be lacking (I wasn't sure if we wanted to assume that a failed apr_proc_detach() was because of a -DNO_DETACH+no-daemontools situation or not). -aaron
Re: Deamon tools
> > > if (setsid() fails)
> > > always log error
> > > exit(1) unless no_detach.
> >
> > should that be
> > exit(1) if no_detach
> > ? or do I have the logic backward?
>
> We should exit if setsid() fails and we don't want to detach (i.e.
> no_detach). If we don't exit at that point we will end up killing processes in
> the wrong pgrp later. So I think Aaron's right.
Now that I think about it a little more, we should probably always
exit if setsid() fails. It might be useful to change the error message
if no_detach is set ("setsid() failed probably because you aren't
running under a process management tool like daemontools" vs "setsid()
failed, unable to create new session"). Then we just do the fork fork()
if !no_detach. Confused yet?
-aaron
Re: cvs commit: httpd-2.0 configure.in
On Mon, May 13, 2002 at 09:23:29PM -, [EMAIL PROTECTED] wrote:
> jerenkrantz02/05/13 14:23:29
>
> Modified:.configure.in
> Log:
> Instead of hardcoding srclib/apr{-util} in the INCLUDES, get the information
> from ap{ru}-config --includes which knows how to deal with VPATH builds
> itself.
This whole push is quite excellent! Good job, Justin!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Deamon tools
Aaron Bannert <[EMAIL PROTECTED]> writes: > I think we should just fail with an error if the user wished to start > up under daemontools mode (no_detach mode) but somehow started httpd > as a process group leader. Concur. > On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote: > > In that case I'd suggest we do > > > > if (setsid() fails) > > always log error > > exit(1) unless no_detach. > > should that be > exit(1) if no_detach > ? or do I have the logic backward? That's correct, dirk had the test inverted. Note that I'm not sure if httpd 2.0 is this robust in handling setsid(2), so if we're spending the time on this and it's considered important for 1.3, someone should probably spend some time on making 2.0 as robust. --michael
Re: Deamon tools
On Mon, May 13, 2002 at 03:23:54PM -0700, Aaron Bannert wrote: > On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote: > > In that case I'd suggest we do > > > > if (setsid() fails) > > always log error > > exit(1) unless no_detach. > > should that be > exit(1) if no_detach > ? or do I have the logic backward? We should exit if setsid() fails and we don't want to detach (i.e. no_detach). If we don't exit at that point we will end up killing processes in the wrong pgrp later. So I think Aaron's right. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Deamon tools
On Mon, May 13, 2002 at 03:15:44PM -0700, [EMAIL PROTECTED] wrote: > In that case I'd suggest we do > > if (setsid() fails) > always log error > exit(1) unless no_detach. should that be exit(1) if no_detach ? or do I have the logic backward? -aaron
Re: Deamon tools
> OTOH, simply calling httpd from the command line (or exec'ing it from > a shell script) will usually mean that the process is the leader of a > new process group, meaning setsid() will fail. I had not considered that mode of use - should we allow for that ? It would propably make sense - seems useful to me. In that case I'd suggest we do if (setsid() fails) always log error exit(1) unless no_detach. Dw
Re: Deamon tools
On Mon, May 13, 2002 at 03:04:01PM -0700, Aaron Bannert wrote:
> I think we should just fail with an error if the user wished to start
> up under daemontools mode (no_detach mode) but somehow started httpd
> as a process group leader.
That's a good idea ("Doctor, it hurts when I poke here." ...).
> -aaron
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Deamon tools
On Mon, May 13, 2002 at 02:50:34PM -0700, [EMAIL PROTECTED] wrote: > > Hmm - not entirely trivial; it turns out that most unix-es do not take > > kindly to > > > > setsid() > > > > when not detached/non-root. So I changed Jos/Michaels patch. See below. > > Anyone any comments ? > > The other obvious way is to make the error non fatal or do a (!geteuid()) > to see if we are running as root. But wait, if we skip the setsid() if !do_detach we will end up killing the parent pgrp which contains - in this case - svscan/supervise/others, which is part of the point of this patch. Am I missing something? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Deamon tools
On Mon, May 13, 2002 at 02:45:12PM -0700, [EMAIL PROTECTED] wrote: > > Hmm - not entirely trivial; it turns out that most unix-es do not take > kindly to > > setsid() > > when not detached/non-root. So I changed Jos/Michaels patch. See below. > Anyone any comments ? Which platforms disallow non-root calls to setsid()? I thought the only requirement for calling setsid() was that the calling process wasn't already the leader of a process group. Daemontools ensurs this by forking and exec()ing the process it is going to manage, meaning that if the parent was a process group leader than the child is guaranteed to not be. OTOH, simply calling httpd from the command line (or exec'ing it from a shell script) will usually mean that the process is the leader of a new process group, meaning setsid() will fail. I think we should just fail with an error if the user wished to start up under daemontools mode (no_detach mode) but somehow started httpd as a process group leader. -aaron
Re: Deamon tools
On Mon, 13 May 2002, Justin Erenkrantz wrote:
> Unified diff, please. =) My brain can't parse that style of
> diffs. -- justin
Hmm - sorry - blame MacOS-X - somehow unified diffs break. Here is one
from a BSD box:
Dw
Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1817
diff -u -r1.1817 CHANGES
--- src/CHANGES 6 May 2002 08:34:13 - 1.1817
+++ src/CHANGES 13 May 2002 21:53:03 -
@@ -1,5 +1,11 @@
Changes with Apache 1.3.25
+ *) Added a '-F' flag; which causes the mother/supervisor process to
+ no longer fork down and detach. But instead stays attached to
+ the tty - thus making live for automatic restart and exit checking
+ code easier. [ Contributed by Michael Handler <[EMAIL PROTECTED]>,
+ Jos Backus <[EMAIL PROTECTED]> [ Dirk-Willem van Gulik ]].
+
*) Make apxs.pl more flexible (file extensions like .so or .dll are
no longer hardcoded). [Stipe Tolj <[EMAIL PROTECTED]>]
Index: src/main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.580
diff -u -r1.580 http_main.c
--- src/main/http_main.c22 Apr 2002 18:23:19 - 1.580
+++ src/main/http_main.c13 May 2002 21:53:05 -
@@ -341,6 +341,8 @@
static int one_process = 0;
+static int do_detach = 1;
+
/* set if timeouts are to be handled by the children and not by the parent.
* i.e. child_timeouts = !standalone || one_process.
*/
@@ -1349,7 +1351,7 @@
#ifdef WIN32
fprintf(stderr, "Usage: %s [-D name] [-d directory] [-f file] [-n service]\n",
bin);
fprintf(stderr, " %s [-C \"directive\"] [-c \"directive\"] [-k signal]\n",
pad);
-fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n", pad);
+fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n", pad);
#else /* !WIN32 */
#ifdef SHARED_CORE
fprintf(stderr, "Usage: %s [-R directory] [-D name] [-d directory] [-f file]\n",
bin);
@@ -1357,7 +1359,7 @@
fprintf(stderr, "Usage: %s [-D name] [-d directory] [-f file]\n", bin);
#endif
fprintf(stderr, " %s [-C \"directive\"] [-c \"directive\"]\n", pad);
-fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n", pad);
+fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n", pad);
fprintf(stderr, "Options:\n");
#ifdef SHARED_CORE
fprintf(stderr, " -R directory : specify an alternate location for shared
object files\n");
@@ -1380,6 +1382,7 @@
#endif
fprintf(stderr, " -t : run syntax check for config files (with
docroot check)\n");
fprintf(stderr, " -T : run syntax check for config files (without
docroot check)\n");
+fprintf(stderr, " -F : run main process in foreground, for process
+supervisors\n");
#ifdef WIN32
fprintf(stderr, " -n name : name the Apache service for -k options
below;\n");
fprintf(stderr, " -k stop|shutdown : tell running Apache to shutdown\n");
@@ -3374,17 +3377,19 @@
!defined(BONE)
/* Don't detach for MPE because child processes can't survive the death of
the parent. */
-if ((x = fork()) > 0)
- exit(0);
-else if (x == -1) {
- perror("fork");
- fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
- exit(1);
+if (do_detach) {
+if ((x = fork()) > 0)
+exit(0);
+else if (x == -1) {
+perror("fork");
+ fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
+ exit(1);
+}
+RAISE_SIGSTOP(DETACH);
}
-RAISE_SIGSTOP(DETACH);
#endif
#ifndef NO_SETSID
-if ((pgrp = setsid()) == -1) {
+if ((do_detach) && ((pgrp = setsid()) == -1)) {
perror("setsid");
fprintf(stderr, "%s: setsid failed\n", ap_server_argv0);
exit(1);
@@ -5312,7 +5317,7 @@
ap_setup_prelinked_modules();
while ((c = getopt(argc, argv,
- "D:C:c:xXd:f:vVlLR:StTh"
+ "D:C:c:xXd:Ff:vVlLR:StTh"
#ifdef DEBUG_SIGSTOP
"Z:"
#endif
@@ -5334,6 +5339,9 @@
case 'd':
ap_cpystrn(ap_server_root, optarg, sizeof(ap_server_root));
break;
+ case 'F':
+ do_detach = 0;
+ break;
case 'f':
ap_cpystrn(ap_server_confname, optarg, sizeof(ap_server_confname));
break;
@@ -7215,9 +7223,9 @@
reparsed = 1;
}
-while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLz:Z:wiuStThk:n:W:")) != -1) {
+while ((c = getopt(argc, argv, "D:C:c:Xd:fF:vVlLz:Z:wiuStThk:n:W:")) != -1) {
#else /* !WIN32 */
-while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLesStTh")) != -1) {
+while ((c = getopt(argc, argv, "D:C:c:Xd:fF:vVlLesStTh")) !
Re: Deamon tools
> Hmm - not entirely trivial; it turns out that most unix-es do not take > kindly to > > setsid() > > when not detached/non-root. So I changed Jos/Michaels patch. See below. > Anyone any comments ? The other obvious way is to make the error non fatal or do a (!geteuid()) to see if we are running as root. Dw
Deamon tools
Hmm - not entirely trivial; it turns out that most unix-es do not take
kindly to
setsid()
when not detached/non-root. So I changed Jos/Michaels patch. See below.
Anyone any comments ?
Dw
Index: CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1817
diff -r1.1817 CHANGES
2a3,8
> *) Added a '-F' flag; which causes the mother/supervisor process to
> no longer fork down and detach. But instead stays attached to
> the tty - thus making live for automatic restart and exit checking
> code easier. [ Contributed by Michael Handler <[EMAIL PROTECTED]>,
> Jos Backus <[EMAIL PROTECTED]> [ Dirk-Willem van Gulik ]].
>
Index: main/http_main.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_main.c,v
retrieving revision 1.580
diff -r1.580 http_main.c
343a344,345
> static int do_detach = 1;
>
1352c1354
< fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n", pad);
---
> fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n", pad);
1360c1362
< fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]\n", pad);
---
> fprintf(stderr, " %s [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F]\n", pad);
1382a1385
> fprintf(stderr, " -F : run main process in foreground, for
>process supervisors\n");
3377,3382c3380,3388
< if ((x = fork()) > 0)
< exit(0);
< else if (x == -1) {
< perror("fork");
< fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
< exit(1);
---
> if (do_detach) {
> if ((x = fork()) > 0)
> exit(0);
> else if (x == -1) {
> perror("fork");
> fprintf(stderr, "%s: unable to fork new process\n", ap_server_argv0);
> exit(1);
> }
> RAISE_SIGSTOP(DETACH);
3384d3389
< RAISE_SIGSTOP(DETACH);
3387c3392
< if ((pgrp = setsid()) == -1) {
---
> if ((do_detach) && ((pgrp = setsid()) == -1)) {
5315c5320
< "D:C:c:xXd:f:vVlLR:StTh"
---
> "D:C:c:xXd:Ff:vVlLR:StTh"
5336a5342,5344
> case 'F':
> do_detach = 0;
> break;
7218c7226
< while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLz:Z:wiuStThk:n:W:")) != -1) {
---
> while ((c = getopt(argc, argv, "D:C:c:Xd:fF:vVlLz:Z:wiuStThk:n:W:")) != -1) {
7220c7228
< while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLesStTh")) != -1) {
---
> while ((c = getopt(argc, argv, "D:C:c:Xd:fF:vVlLesStTh")) != -1) {
7341a7350,7352
> case 'F':
> do_detach = 0;
> break;
7736c7747
< while ((c = getopt(argc, argv, "D:C:c:Xd:f:vVlLR:SZ:tTh")) != -1) {
---
> while ((c = getopt(argc, argv, "D:C:c:Xd:Ff:vVlLR:SZ:tTh")) != -1) {
7742a7754
> case 'F':
--
Dirk-Willem van Gulik
Re: 1.3.26
Ok - massaged the right patch in - works perfectly on MacOS X. Testing further. Dw. -- Dirk-Willem van Gulik On Mon, 13 May 2002, Jim Jagielski wrote: > Jim Jagielski wrote: > > > > At 12:25 PM -0701 5/13/02, Jos Backus wrote: > > >Anyone interested in picking this up before the next (last?) 1.3 release? > > > > > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 > > > > > >Please? Thanks! > > > > > > > The URL in the bug report >(http://lizzy.dyndns.org/~jos/apache-1.3.24-daemontools.patch) > > > > appears bogus. > > Although > > http://www.catnook.com/patches/apache-1.3.24-daemontools.patch > > is valid. To the point, however, the bug says to simply place in > ./patches, but I'm wondering whether we should just fold it into > the official source. That's what I'm leaning towards... Any complaints > if, after review and test, we do that?? >
Re: 1.3.26
> http://www.catnook.com/patches/apache-1.3.24-daemontools.patch > > is valid. To the point, however, the bug says to simply place in > ./patches, but I'm wondering whether we should just fold it into > the official source. That's what I'm leaning towards... Any complaints > if, after review and test, we do that?? My intention was to review, test and fold into the core. Dw
Re: 1.3.26
On Mon, May 13, 2002 at 01:29:23PM -0700, Aaron Bannert wrote: > On Mon, May 13, 2002 at 12:25:39PM -0701, Jos Backus wrote: > > Anyone interested in picking this up before the next (last?) 1.3 release? > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 > > I would like to see this go in to 1.3. I will volunteer my time to see > that this happens (the patch is there, it just needs to be merged), if > I can get enough support. I realize this might be considered a feature, > but I think it is something that is needed and will be very useful for > those who are stuck on 1.3 for the time being. Thank you very much! > -aaron -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: 1.3.26
Jim Jagielski wrote: > > At 12:25 PM -0701 5/13/02, Jos Backus wrote: > >Anyone interested in picking this up before the next (last?) 1.3 release? > > > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 > > > >Please? Thanks! > > > > The URL in the bug report >(http://lizzy.dyndns.org/~jos/apache-1.3.24-daemontools.patch) > > appears bogus. Although http://www.catnook.com/patches/apache-1.3.24-daemontools.patch is valid. To the point, however, the bug says to simply place in ./patches, but I'm wondering whether we should just fold it into the official source. That's what I'm leaning towards... Any complaints if, after review and test, we do that?? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: 1.3.26
At 12:25 PM -0701 5/13/02, Jos Backus wrote: >Anyone interested in picking this up before the next (last?) 1.3 release? > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 > >Please? Thanks! > The URL in the bug report (http://lizzy.dyndns.org/~jos/apache-1.3.24-daemontools.patch) appears bogus. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: 1.3.26
On Mon, May 13, 2002 at 12:25:39PM -0701, Jos Backus wrote: > Anyone interested in picking this up before the next (last?) 1.3 release? > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 I would like to see this go in to 1.3. I will volunteer my time to see that this happens (the patch is there, it just needs to be merged), if I can get enough support. I realize this might be considered a feature, but I think it is something that is needed and will be very useful for those who are stuck on 1.3 for the time being. -aaron
Re: 1.3.26
Anyone interested in picking this up before the next (last?) 1.3 release? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7628 Please? Thanks! -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: PROPOSAL: Release 1.3.25
Stipe Tolj wrote: > > David Reid wrote: > > > > What about fixing build issues? > > > > ab is currently broken on non writev and non ssl platforms (though I have > > Dirk's patch applied and it correct the issue) and I have one other small > > patch I'd like to finish and then apply to allow a build for beos to > > complete... > > > > I'll hopefully get the patch done today and send it. > > > > I'm +1 on a 1.3.25 though > > can we add a couple of Cygwin specific build issues too before > shooting 1.3.25? > > I'll send a patch in ASAP. > +1... (on both) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: PROPOSAL: Release 1.3.25
David Reid wrote: > > What about fixing build issues? > > ab is currently broken on non writev and non ssl platforms (though I have > Dirk's patch applied and it correct the issue) and I have one other small > patch I'd like to finish and then apply to allow a build for beos to > complete... > > I'll hopefully get the patch done today and send it. > > I'm +1 on a 1.3.25 though can we add a couple of Cygwin specific build issues too before shooting 1.3.25? I'll send a patch in ASAP. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
PR 8482: server push CGIs broken
The PR was written for nph CGIs but it appears that any server push CGI is broken. Apparently, core_output_filter() would need to switch between non-blocking and blocking bucket reads (and flush the output in-between) to get this to work. For non-nph server push CGIs to work, other filters which buffer data may need something similar... Comments? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] 1.3: Stricter check on request_line format
On Mon, May 13, 2002 at 01:58:38PM +0200, Kraemer, Martin wrote: > @@ -1045,12 +1045,26 @@ > r->assbackwards = (ll[0] == '\0'); > r->protocol = ap_pstrdup(r->pool, ll[0] ? ll : "HTTP/0.9"); > > -if (2 == sscanf(r->protocol, "HTTP/%u.%u", &major, &minor) > +if (3 == sscanf(r->protocol, "HTTP/%u.%u%n", &major, &minor, &n) No, that should have been if (2 == sscanf(r->protocol, "HTTP/%u.%u%n", &major, &minor, &n) because %n does not increment the item count. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: [PATCH] 1.3: Stricter check on request_line format
Okay, once again _with_ patch:
We have been discussing this topic in the past: a stricter check
should be applied to the request line, in order to prevent arbitrary
user input to end up in the access_log and error_log. It could be
misused to spoof accesses to nonexistent (or inaccessible) resources,
of course without the client actually getting access to them.
The solution I present here exists of two separate issues:
1) Detecting and disallowing garbage in the request line.
Stuff like the 'planted' string:
% echo 'GET / HTTP/1.0" 304 -\r207.46.197.102 - - [01/May/2002:00:02:25 +0200]
"GET / HTTP/1.0\n' \
| netcat www.apache.org 80
until now looks like there was an access from 207.46.197.102,
at least to the admin doing a "tail access_log", and maybe to
some log analyzers too. So, any garbage after the correct
syntax for a request
(like in "GET / HTTP/1.1") should be disallowed and logged.
2) Escaping dangerous characters in the log files.
Today, you can cause almost any character to appear in the logs.
Simply do a "echo '[2J' | netcat localhost 80" and if the
administrator has a "tail -f access_log" running in some window,
it will be cleared at this point.
Now we don't want to break existing log analyzers, but escaping
such b**t is definitely useful. What I do in this patch is
to add another escaping class T_ESCAPE_LOGITEM and use it on
items that *might* have come from the user (i.e., the 'tainted'
items request line, request MIME header lines, possibly DNS
reverse lookup names, ...). I escape invalid chars in \xXX
syntax, except for '"', '\\' itself and '\r', '\n', '\b', '\t'
which are simply escaped by preceding them with a '\\'. Thus it is
possible to distinguish a (client-provided) '\\' from a '\\' inserted
by the escaper. The extra escaping of '"' was added to prevent
spoofing attemps (in the CLF, the request line is enclosed in '"',
and it was easy to add a '"' to the request and confuse the reader
of the log file, see example above).
The patch does not (yet) try to filter *every* log item through the
log filter, because apache users may want to add special characters
to the log at their discretion (using LogFormat). But the typical
abuse is caught (and logged) in a sensible manner.
Comments?
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Index: include/httpd.h
===
RCS file: /home/cvs/apachen/src/include/httpd.h,v
retrieving revision 1.185
diff -u -r1.185 httpd.h
--- include/httpd.h 9 Apr 2002 09:31:13 - 1.185
+++ include/httpd.h 13 May 2002 11:22:16 -
@@ -1032,6 +1032,7 @@
API_EXPORT(char *) ap_escape_html(pool *p, const char *s);
API_EXPORT(char *) ap_construct_server(pool *p, const char *hostname,
unsigned port, const request_rec *r);
+API_EXPORT(char *) ap_escape_logitem(pool *p, const char *str);
API_EXPORT(char *) ap_escape_shell_cmd(pool *p, const char *s);
API_EXPORT(int) ap_count_dirs(const char *path);
Index: main/gen_test_char.c
===
RCS file: /home/cvs/apachen/src/main/gen_test_char.c,v
retrieving revision 1.7
diff -u -r1.7 gen_test_char.c
--- main/gen_test_char.c22 Mar 2002 20:53:04 - 1.7
+++ main/gen_test_char.c13 May 2002 11:22:16 -
@@ -8,6 +8,7 @@
#define T_ESCAPE_PATH_SEGMENT (0x02)
#define T_OS_ESCAPE_PATH (0x04)
#define T_HTTP_TOKEN_STOP (0x08)
+#define T_ESCAPE_LOGITEM (0x10)
int main(int argc, char *argv[])
{
@@ -16,25 +17,27 @@
printf(
"/* this file is automatically generated by gen_test_char, do not edit */\n"
-"#define T_ESCAPE_SHELL_CMD(%u)\n"
-"#define T_ESCAPE_PATH_SEGMENT (%u)\n"
-"#define T_OS_ESCAPE_PATH (%u)\n"
-"#define T_HTTP_TOKEN_STOP (%u)\n"
-"\n"
-"static const unsigned char test_char_table[256] = {\n"
-"0,",
+"#define T_ESCAPE_SHELL_CMD0x%02x /* chars with special meaning in the shell */\n"
+"#define T_ESCAPE_PATH_SEGMENT 0x%02x /* find path segment, as defined in RFC1808
+*/\n"
+"#define T_OS_ESCAPE_PATH 0x%02x /* escape characters in a path or uri */\n"
+"#define T_HTTP_TOKEN_STOP 0x%02x /* find http tokens, as defined in RFC2616 */\n"
+"#define T_ESCAPE_LOGITEM 0x%02x /* filter what should go in the log file */\n"
+"\n",
T_ESCAPE_SHELL_CMD,
T_ESCAPE_PATH_SEGMENT,
T_OS_ESCAPE_PATH,
- T_HTTP_TOKEN_STOP);
+ T_HTTP_TOKEN_STOP,
+ T_ESCAPE_LOGITEM
+ );
/* we explicitly dealt with NUL above
* in case some strchr() do bogosity with it */
+printf("static const unsigned char test_char_table[256] = {\n"
+ "0x00, ");/* print initial item */
+
for (c = 1; c < 256; ++c) {
flags = 0;
- if (c % 20 == 0
[PATCH] 1.3: Stricter check on request_line format
We have been discussing this topic in the past: a stricter check should be applied to the request line, in order to prevent arbitrary user input to end up in the access_log and error_log. It could be misused to spoof accesses to nonexistent (or inaccessible) resources, of course without the client actually getting access to them. The solution I present here exists of two separate issues: 1) Detecting and disallowing garbage in the request line. Stuff like the 'planted' string: % echo 'GET / HTTP/1.0" 304 -\r207.46.197.102 - - [01/May/2002:00:02:25 +0200] "GET / HTTP/1.0\n' \ | netcat www.apache.org 80 until now looks like there was an access from 207.46.197.102, at least to the admin doing a "tail access_log", and maybe to some log analyzers too. So, any garbage after the correct syntax for a request (like in "GET / HTTP/1.1") should be disallowed and logged. 2) Escaping dangerous characters in the log files. Today, you can cause almost any character to appear in the logs. Simply do a "echo '[2J' | netcat localhost 80" and if the administrator has a "tail -f access_log" running in some window, it will be cleared at this point. Now we don't want to break existing log analyzers, but escaping such b**t is definitely useful. What I do in this patch is to add another escaping class T_ESCAPE_LOGITEM and use it on items that *might* have come from the user (i.e., the 'tainted' items request line, request MIME header lines, possibly DNS reverse lookup names, ...). I escape invalid chars in \xXX syntax, except for '"', '\\' itself and '\r', '\n', '\b', '\t' which are simply escaped by preceding them with a '\\'. Thus it is possible to distinguish a (client-provided) '\\' from a '\\' inserted by the escaper. The extra escaping of '"' was added to prevent spoofing attemps (in the CLF, the request line is enclosed in '"', and it was easy to add a '"' to the request and confuse the reader of the log file, see example above). The patch does not (yet) try to filter *every* log item through the log filter, because apache users may want to add special characters to the log at their discretion (using LogFormat). But the typical abuse is caught (and logged) in a sensible manner. Comments? Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
DEFAULT_XFERLOG in apache-1.3
I noticed that the DEFAULT_XFERLOG macro definition is
supplied but not used anywhere in apache_1.3.
The only place where we use the definition is in "httpd -V"
where we print its setting.
% find . -type f | xargs grep -i DEFAULT_XFERLOG
./src/main/http_main.c:#ifdef DEFAULT_XFERLOG
./src/main/http_main.c:printf(" -D DEFAULT_XFERLOG=\"" DEFAULT_XFERLOG "\"\n");
./src/apaci:echo '-DDEFAULT_XFERLOG="logs/access_log"'
./src/include/httpd.h:#ifndef DEFAULT_XFERLOG
./src/include/httpd.h:#define DEFAULT_XFERLOG "logs/access.log"
./src/include/httpd.h:#define DEFAULT_XFERLOG "logs/access_log"
./src/include/httpd.h:#endif /* DEFAULT_XFERLOG */
./configure:echo " DEFAULT_XFERLOG: ${logfiledir_relative}access_log"
./configure:echo "echo '-DDEFAULT_XFERLOG=\"${logfiledir_relative}access_log\"'"
>>$src/apaci
I vote for deleting it. In absense of a TransferLog or
CustomLog directive, apache_1.3 (today) does no access logging
at all.
Objections?
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: beware of intermittent mod_auth failures...
On Mon, May 13, 2002 at 06:47:00AM -0400, Jeff Trawick wrote: > crypt() is fine if it uses thread-specific storage (like Solaris, > OS/390, HP-UX); that's a better fix than adding crypt_r() since old Are there any BSD-licensed sources that uses thread-specific storage for crypt() that we can (attempt to) throw into Darwin's libc? -- justin
Re: beware of intermittent mod_auth failures...
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > On Fri, May 10, 2002 at 04:41:52PM -0400, Jeff Trawick wrote: > > ...on Linux and AIX and perhaps some other platforms with a threaded > > MPM and crypt() passwords. I saw it myself on AIX before teaching APR > > to use crypt_r(). Somebody else at IBM saw it on both AIX and Linux. > > > > This should be fixed as of a couple of hours ago on Linux and AIX. No > > change should be necessary on Solaris, OS/390, and HP-UX. I dunno > > about the other platforms where threads work well enough for Apache. > > Darwin looks like its screwed - it's using a static buffer. crypt() is fine if it uses thread-specific storage (like Solaris, OS/390, HP-UX); that's a better fix than adding crypt_r() since old code just works and since you avoid the mess regarding the lack of a standard interface to crypt_r() (maybe I'll find time to write a test pgm to see if crypt() returns thread-specific storage) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
