Re: [PATCH] Patch to compile apache-1.3.20+ on LynxOS-3.0.1

[Fulvio Bille`]

Hi.
I have LynxOS 3.0.1 on 68k, and I confirm that find doesn't have the option
"-depth".

I'm sorry but I think that the mailer have wrapped some line of the patch,
corrupting its.
So I re-send the patch as attachment.
Bye.

Jim Jagielski wrote:

> The patches look acceptable, except for the below... Why the change?
> '-depth' not supported in LynxOS's find?
>


diff -ruN ./src/Configure ../apache_1.3.26-patched/src/Configure
--- ./src/Configure Tue Jun 18 07:20:33 2002
+++ ../apache_1.3.26-patched/src/Configure  Fri Jul  5 14:11:18 2002
@@ -472,6 +472,13 @@
LIBS="$LIBS -lbsd -lcrypt"
DEF_WANTHSREGEX=yes
;;
+*-lynx-lynxos3)
+   OS='LynxOS 3.x'
+   CFLAGS="$CFLAGS -D__NO_INCLUDE_WARN__ -DLYNXOS3"
+   LIBS="$LIBS -lbsd -lcrypt"
+   DEF_WANTHSREGEX=yes
+   INCLUDES=-I/usr/include
+   ;;
 *486-*-bsdi*)
OS='BSDI w/486'
CFLAGS="$CFLAGS -m486"
diff -ruN ./src/helpers/GuessOS ../apache_1.3.26-patched/src/helpers/GuessOS
--- ./src/helpers/GuessOS   Mon Oct  8 17:49:33 2001
+++ ../apache_1.3.26-patched/src/helpers/GuessOSFri Jul  5 14:11:18 2002
@@ -134,6 +134,10 @@
echo "${MACHINE}-GNU-GNU/Hurd"; exit 0
;;
 
+LynxOS:3*:*)
+   echo "${MACHINE}-lynx-lynxos3"; exit 0
+   ;;
+
 LynxOS:*)
echo "${MACHINE}-lynx-lynxos"; exit 0
;;
diff -ruN ./src/helpers/mkshadow.sh ../apache_1.3.26-patched/src/helpers/mkshadow.sh
--- ./src/helpers/mkshadow.sh   Tue Jun 29 15:43:15 1999
+++ ../apache_1.3.26-patched/src/helpers/mkshadow.shFri Jul  5 14:11:19 2002
@@ -65,7 +65,7 @@
 
 #   fill directory tree with symlinks to files
 FILES="`cd $src; \
-find . -depth -print |\
+find . -print |\
 sed -e '/\.o$/d' \
 -e '/\.a$/d' \
 -e '/\.so$/d' \
diff -ruN ./src/include/ap_config.h ../apache_1.3.26-patched/src/include/ap_config.h
--- ./src/include/ap_config.h   Mon Jun  3 14:28:27 2002
+++ ../apache_1.3.26-patched/src/include/ap_config.hWed Jul 10 11:03:59 2002
@@ -787,6 +787,22 @@
 typedef int rlim_t;
 #define HAVE_SYSLOG 1
 
+#elif defined(LYNXOS3)
+#undef HAVE_GMTOFF
+#undef USE_MMAP_SCOREBOARD
+#undef USE_SHMGET_SCOREBOARD
+#undef USE_POSIX_SCOREBOARD
+#define HAVE_FCNTL_SERIALIZED_ACCEPT
+#define USE_FCNTL_SERIALIZED_ACCEPT
+#define USE_LONGJMP
+#undef NO_KILLPG
+#undef NO_SETSID
+#undef NO_USE_SIGACTION
+#undef NO_LINGCLOSE
+extern char *crypt(char *pw, char *salt);
+typedef long rlim_t;
+#define HAVE_SYSLOG 1
+
 #elif defined(UXPDS)
 #undef NEED_STRCASECMP
 #undef NEED_STRNCASECMP

apr_poll() done.

[Ryan Bloom]

Thanks to Will doing the work for Windows, the apr_poll() move is done.
Most of the current platforms are actually using a select() based
implementation, so instead of duplicating logic again, every platform
except for OS/2 is using the Unix poll.c file.

The only implementation that is likely to work currently is the Unix
implementation.  The test suite does have a testpoll.c, which can tell
you if the implementation is working, although it is hard to determine
if the tests were successful.  The important lines are the ones that
give the socket status.  There should be five of these lines, and they
should look like:

Socket 0Socket 1Socket 2
No wait No wait No wait
No wait No wait POLLIN!
No wait POLLIN! No wait
No wait POLLIN! POLLIN!
POLLIN! No wait POLLIN!


The other test that you should run is testpipe.  Remember that
apr_file_read and apr_file_write use apr_wait_for_io_or_timeout, and
that now uses apr_poll().  This means that if the apr_poll()
implementation doesn't work on your platform, CGI scripts and any other
pipe-based request will fail.

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

RE: quick docs patch..

[James Cox]

Well,

we have two (maybe 3) options. We can either kill it all, or keep it
up-to-date, or just ignore them, and label them so but having links that
end up as 404's probably don't help, imho.

 -- james

>
> At 02:21 AM 7/1/2002, you wrote:
> >Quick patch to bring some old docs up-to-date.
>
> Do we even care to freshen these?  Seems like it's about time to
> kill this bird.
>
> Bill
>
> >--
> >James Cox :: [EMAIL PROTECTED] :: Landonize It! http://landonize.it/
> >Was I helpful?
> http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/
>
>
>

Re: quick docs patch..

[William A. Rowe, Jr.]

At 02:21 AM 7/1/2002, you wrote:
>Quick patch to bring some old docs up-to-date.

Do we even care to freshen these?  Seems like it's about time to
kill this bird.

Bill

>--
>James Cox :: [EMAIL PROTECTED] :: Landonize It! http://landonize.it/
>Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/

[STATUS] (httpd-2.0) Wed Jul 10 23:45:09 EDT 2002

[Rodent of Unusual Size]

APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2002/06/28 20:16:26 $]

Release:

2.0.40  : in development.
2.0.39  : rolled June 17, 2002.
2.0.38  : rolled June 16, 2002.  not released.
2.0.37  : rolled June 11, 2002.  not released.
2.0.36  : released May 6, 2002 as GA.
2.0.35  : released April 5, 2002 as GA.
2.0.34  : tagged March 26, 2002.
2.0.33  : tagged March 6, 2002.  not released.
2.0.32  : released Feburary 16, 2002 as beta.
2.0.31  : rolled Feburary 1, 2002.  not released.
2.0.30  : tagged January 8, 2002.  not rolled.
2.0.29  : tagged November 27, 2001.  not rolled.
2.0.28  : released November 13, 2001 as beta.
2.0.27  : rolled November 6, 2001
2.0.26  : tagged October 16, 2001.  not rolled.
2.0.25  : rolled August 29, 2001
2.0.24  : rolled August 18, 2001
2.0.23  : rolled August 9, 2001
2.0.22  : rolled July 29, 2001
2.0.21  : rolled July 20, 2001
2.0.20  : rolled July 8, 2001
2.0.19  : rolled June 27, 2001
2.0.18  : rolled May 18, 2001
2.0.17  : rolled April 17, 2001
2.0.16  : rolled April 4, 2001
2.0.15  : rolled March 21, 2001
2.0.14  : rolled March 7, 2001
2.0a9   : released December 12, 2000
2.0a8   : released November 20, 2000
2.0a7   : released October 8, 2000
2.0a6   : released August 18, 2000
2.0a5   : released August 4, 2000
2.0a4   : released June 7, 2000
2.0a3   : released April 28, 2000
2.0a2   : released March 31, 2000
2.0a1   : released March 10, 2000

Please consult the following STATUS files for information
on related projects:

* srclib/apr/STATUS
* srclib/apr-util/STATUS
* docs/STATUS


CURRENT RELEASE NOTES:


RELEASE SHOWSTOPPERS:

* apr_sendfile() is broken on FreeBSD 4.6-STABLE as of 20020627 (and 
  presumably more leading edge levels) because of a "fix" in the kernel.
  Apache 2.0.39 is unreliable on that kernel.

CURRENT VOTES:

* apachectl should revert to just being an init script and
  httpd.sh should be the wrapper for httpd which sources envvars
  and allows any options to be passed through

  +1:  trawick

* Should we always build [support*] binaries statically unless otherwise
  indicated?
Message-ID: <[EMAIL PROTECTED]>

  +1:  Ken, *wrowe [they are PITAs on OSX]
  -1:  Justin, Ian

* If the parent process dies, should the remaining child processes
  "gracefully" self-terminate. Or maybe we should make it a runtime
  option, or have a concept of 2 parent processes (one being a 
  "hot spare").
  See: Message-ID: <[EMAIL PROTECTED]>

  Self-destruct: Ken, Martin
  Not self-destruct: BrianP, Ian, Cliff, BillS
  Make it runtime configurable: Aaron, Jim, Justin
  Have 2 parents: +1: Jim
  -1: Justin, wrowe [for 2.0]
  +0: Martin (while standing by, could it do
  something useful?)

* Make the worker MPM the default MPM for threaded Unix boxes.
  +1:   Justin, Ian, Cliff, BillS
  +0:   BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing)
  -0:   Lars

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

* All handlers should always send content down even if r->header_only
  is set.  If not, it means that the HEAD requests don't generate the
  same headers as a GET which is wrong.
  Is this a showstopper?
+1: Justin
-1: Aaron

* server pushed CGI's not working.  (Is this a showstopper??)
  PR: 8482
  Message-ID: <[EMAIL PROTECTED]>

* HP/UX 10.20: compile breakage in APR.  Looks like it should be easy
  to fix, probably just some extraneous #include's that are fouling
  things up.
  PR: 9457
  Jeff: See my reply and patch in the PR (and previous commit to
  stop using "pipe" as a field name).  If patch is committed, we
  should be okay.  I'll wait to see if the user tests the patch.

* exec cmd and suexec arg-passing enhancements
  Status: Patches proposed
  Message-ID: <[EMAIL PROTECTED]>
  (see the "proc.patch" and "suexec-shell.patch" links in this message)

* Get mod_cache/mod_mem_cache out of experimental (still some
  work items left to complete)

* The 2.0.36 worker MPM graceless shutdown changes work but are
  a bit clunky on some platforms; eg, on Linux, the loop to
  join each worker thread seems to hang, and the parent ends up
  killing off the child with SIGKILL.  But at least it shuts down.

* --enable-mods-shared="foo1 foo2" is busted on Darwin.  Pier
posted a patch (Message-ID: <[EMAIL PROTECTED]>).

* We do not properly substitute the prefix-variables in the configuration
  scripts or generated-configs.  (i.e. if sysconfdir is etc,
  httpd-std.conf point

[STATUS] (apache-1.3) Wed Jul 10 23:45:06 EDT 2002

[Rodent of Unusual Size]

APACHE 1.3 STATUS:  -*-text-*-
  Last modified at [$Date: 2002/06/27 20:57:21 $]

Release:

   1.3.27-dev: In development
   1.3.26: Tagged June 18, 2002.
   1.3.25: Tagged June 17, 2002. Not released.
   1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002.
   1.3.23: Tagged Jan 21, 2002.
   1.3.22: Tagged Oct 8, 2001.  Announced Oct 12, 2001.
   1.3.21: Not released.
 (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001)
   1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001.
   1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001.
   1.3.18: Tagged and rolled Not released.
 (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001)
   1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001.
   1.3.16: Not released.
 (Pulled because of vhosting bug. t/r Jan 20, 2001)
   1.3.15: Not released.
 (Pulled due to CVS dumping core during the tagging when it
  reached src/os/win32/)
   1.3.14: Tagged and Rolled Oct 10, 2000.  Released/announced on the 13th.
   1.3.13: Not released.
 (Pulled in the "first minutes" due to a Netware build bug)
   1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th.
   1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st.
   1.3.10: Not released.
 (Pulled at "last minute" due to a build bug in the MPE port)
1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th.
1.3.8: Not released.
1.3.7: Not released.
1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th.
1.3.5: Not released.
1.3.4: Tagged and rolled on Jan. 9.  Released on 11th, announced on 12th.
1.3.3: Tagged and rolled on Oct. 7.  Released on 9th, announced on 10th.
1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd.
1.3.1: Tagged and rolled on July 19. Announced and released.
1.3.0: Tagged and rolled on June 1.  Announced and released on the 6th.
   
2.0  : Available for general use, see httpd-2.0 repository

RELEASE SHOWSTOPPERS:

   * Current vote on 2 PRs for inclusion:
  Bugz #9181 (Unable to set headers on non-2XX responses)
+1: Martin, Jim
  Gnats #10246 (Add ProxyConnAllow directive)
+0: Martin (or rather -.5, see dev@ Message
<[EMAIL PROTECTED]>)

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

* htpasswd.c and htdigest.c use tmpnam()... consider using
  mkstemp() when available.
Message-ID: <[EMAIL PROTECTED]>
Status:

* Dean's "unescaping hell" (unescaping the various URI components
  at the right time and place, esp. unescaping the host name).
Message-ID: <[EMAIL PROTECTED]>
Status:

* Martin observed a core dump because a ipaddr_chain struct contains
  a NULL-"server" pointer when being dereferenced by invoking "httpd -S".
Message-ID: <[EMAIL PROTECTED]>
Status: Workaround enabled. Clean solution can come after 1.3.19

* long pathnames with many components and no AllowOverride None
  Workaround is to define  with AllowOverride None,
  which is something all sites should do in any case.
Status: Marc was looking at it.  (Will asks 'wasn't this patched?')

* Ronald Tschalär's patch to mod_proxy to allow other modules to
  set headers too (needed by mod_auth_digest)
Message-ID: <[EMAIL PROTECTED]>
Status:


Available Patches (Most likely, will be ported to 2.0 as appropriate):

   * Backport of 2.0 ForceLanguagePriority directive
   /dist/httpd/contrib/patches/1.3/force_language_priority.patch
   Message-ID: <[EMAIL PROTECTED]>
   Status:

   *  A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker
 <[EMAIL PROTECTED]> to more fully close some segfault potential.
Message-ID: 
Status:  Jim +1 (for 1.3.19), Martin +0

* Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1, Jim +1, Ken +1 (on concept)

* Raymond S Brand's path to mod_autoindex to fix the header/readme
  include processing so the envariables are correct for the included
  documents.  (Actually, there are two variants in the patch message,
  for two different ways of doing it.)
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1(concept)

* Jayaram's patch (10/27/99) for bugfix to mod_autoindex
  IndexIgnore  should hide the files with this file-
  extension in directory listings. This was NOT happening because the 
  total filename was being compared with the file-extension.
  Status: Martin +1(untested), Ken +1(untested)
   
* Salvador Ortiz Garcia <[EMAIL PROTECTED]>' patch to allow DirectoryIndex
  to refer to URIs for non-static resources.
MID: <[EMAIL PROTECTED]>
Statu

RE: Apache 2 instruction count profile (head as of ~15:00 EDT July 10)

[Bill Stoddard]

Looks like your last commit to apr_tables.c was 4 days ago. This run was
using code I pulled from CVS this afternoon.

Bill

>
> Bill Stoddard wrote:
>
> >Subroutine Name  Source File  Visit
> Enter  %   Ticks
> >===  ===  =
> =  =
> >.ap_rgetline_coreprotocol.c   366
>   1.5 709
> >
>
> Darn, all that optimization work and it's still at the top of the list.
>
> >Shlib Subroutine Source File  Visit
> Enter  %   Ticks
> > ===  =
> =  =
> >.apr_palloc  apr_pools.c  7878
>   2.9 1404
> >.__is_wctype_std libc/__is_wctype_std.c   6666
>   2.8 1320
> >.apr_table_get   apr_tables.c 2117
>   2.6 1229
> >.__divu64divu64.s 3 3
>   2.0 976
> >.__divi64divi64.s 4 4
>   1.9 917
> >.apr_table_setn  apr_tables.c 2412
>   1.6 781
> >
>
> Was this with the latest version of the apr_table code?  If so, I've
> run out of ways to speed up apr_table_get() and apr_table_setn() without
> changing the internal data structure used by the tables to something
> that supports faster-than-O(n) lookups.
>
> --Brian
>
>

Re: Auth - how much legacy to preserve ?

[William A. Rowe, Jr.]

At 04:27 PM 7/10/2002, [EMAIL PROTECTED] wrote:

>On Wed, 10 Jul 2002, Pier Fumagalli wrote:
>
> > Dirk, since you're working on a patch for Auth, would it be possible to 
> have
> > the groups list somewhere in the request structure? It would be great with
> > web applications, where we can match groups with roles (therefore allowing
> > authentication to be processed by apache entirely)...
>
>Well - r->user, or any r->credentials are valid there; as they come from
>the protocol; i.e. are part of the request.
>
>The group information can, depending on protocol, come from more than one
>source
>
> -> provided with the credentials (e.g. like the 'account'
>dimension in ftp or your kerberos realm).
>
> -> a user can belong to N groups as returned by an
>all knowing auth system when asked.
>
> -> a check if the user was in a list of M groups can have
>yieled that he was a member of P groups which is a
>subset of M.
>
>Once you add group; there are other dimensions too; i.e. think of the
>login.conf resources on BSD, a much more mature framework like that on
>mainframes, and so on.

Very cool.

Are you also considering multiple 'user' identities?  E.g., If I'm using client
cert ssl auth [one identity], with basic encryption [a different identity], it
would be nice to walk the 'identities' list.

In that, you could have several types of 'identities' in a list, e.g. 'user',
'group', 'role', etc.  The IP and DNS of the client themselves are also
'identities', although they are addresses.

It would be nice to mix 'n match all of these into a single API.

Bill

httpd-ldap maintained?

[Scott Lamb]

Is httpd-ldap being maintained? Is this the appropriate list to ask 
about it?

With the worker MPM, it seems to work - ldap_status doesn't ever show 
anything being cached, but mod_auth_ldap authenticates correctly.

With the prefork MPM (I had unrelated problems with worker), it's going 
horribly wrong. Still ldap_status doesn't show anything being cached. 
Connections accumulate until OpenLDAP runs out of filehandles and bad 
things happen.

Is this a known problem? Any workaround?

Thanks,
Scott Lamb

Re: Auth - how much legacy to preserve ?

[Pier Fumagalli]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> 
> On Wed, 10 Jul 2002, Pier Fumagalli wrote:
> 
>> Dirk, since you're working on a patch for Auth, would it be possible to have
>> the groups list somewhere in the request structure? It would be great with
>> web applications, where we can match groups with roles (therefore allowing
>> authentication to be processed by apache entirely)...
> 
> Well - r->user, or any r->credentials are valid there; as they come from
> the protocol; i.e. are part of the request.
> 
> The group information can, depending on protocol, come from more than one
> source
> 
> -> provided with the credentials (e.g. like the 'account'
>   dimension in ftp or your kerberos realm).
> 
> -> a user can belong to N groups as returned by an
>   all knowing auth system when asked.
> 
> -> a check if the user was in a list of M groups can have
>   yieled that he was a member of P groups which is a
>   subset of M.
> 
> Once you add group; there are other dimensions too; i.e. think of the
> login.conf resources on BSD, a much more mature framework like that on
> mainframes, and so on.
> 
> So this is perhaps a bit more complex than just that.
> 
> What is it you would feel as most useful in the web application world -
> could you elaborate ?

Indeed it is complex...

Basically, a web application in java land specifies some "security
constraints" in the "web.xml" file (its deployment descriptor). It relies on
two main concepts: user (doh!) and a thing called "role" which is more or
less the parallel of a group. Each user can have zero-or-more of these
"roles" (can be in zero or more groups with the current mod_auth).

Given the idea that I want my entire web site to be controlled by (let's
say) a single user/groups database, I need to pass to the servlet container
the list of "roles" to which every user is associated with, therefore its
list of groups, because at any time (even if the servlet is not under any
particular security constraint), someone might call the "isUserInRole" call,
and verify if a user is actually in a particular group...

I can do that passing the list of groups to the roles to the servlet
container, or calling back Apache and if mod_auth could provide a hook to
verify a particular user/role association, that would be even great...

Does this make sense?

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]

RE: Apache 2 instruction count profile (head as of ~15:00 EDT July 10)

[Sander Striker]

> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: 10 July 2002 22:55

> > From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
> > 
> > This is with Ryan's poll patch and some of my patches to mod_cache and
> > mod_mem_cache (which I will publish later on).  Unfortuanetely the
> results
> > are difficult to compare with earlier results because my test tree was
> > just
> > too polluted with patches for Ryan's patch to cleanly apply.  Still,
> the
> > overall direction is good (7.5% reduction in instruction count). The
> > difference between Jeff's wait_for_timeout and Ryan's is noise in this
> > comparison. However, I suspect the apr_poll() is better in general and
> is
> > contributing to the improvement.
> 
> Based on these numbers, I would like to commit the new apr_poll() today.
> This is likely to break everything but Unix for a few days however.
> Once the code is committed, there are some obvious performance
> improvements that can still be made.  The first, is to use a static
> array for small poll sets, or use alloca on systems that have it.  The
> second is to go through Apache and remove the functions that used to
> setup poll sets.  That will actually have an impact on all of the Unix
> MPMs, because we will finally be able to stop re-inserting the same
> socket into the pollset for every request.
> 
> Does anybody have a problem with this plan?  I would like to commit late
> this evening, which will give me enough time to fix Windows tonight
> (hopefully).

Just for the record, my last night of sleep kinda resolved my reservations.
I'm +1 (the performance numbers did the trick of going from +0 to +1).

Sander

Re: Apache 2 instruction count profile (head as of ~15:00 EDT July 10)

[Thom May]

* Ryan Bloom ([EMAIL PROTECTED]) wrote :
> > From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
> > 
> > This is with Ryan's poll patch and some of my patches to mod_cache and
> > mod_mem_cache (which I will publish later on).  Unfortuanetely the
> results
> > are difficult to compare with earlier results because my test tree was
> > just
> > too polluted with patches for Ryan's patch to cleanly apply.  Still,
> the
> > overall direction is good (7.5% reduction in instruction count). The
> > difference between Jeff's wait_for_timeout and Ryan's is noise in this
> > comparison. However, I suspect the apr_poll() is better in general and
> is
> > contributing to the improvement.
> 
> Based on these numbers, I would like to commit the new apr_poll() today.
> This is likely to break everything but Unix for a few days however.
> Once the code is committed, there are some obvious performance
> improvements that can still be made.  The first, is to use a static
> array for small poll sets, or use alloca on systems that have it.  The
> second is to go through Apache and remove the functions that used to
> setup poll sets.  That will actually have an impact on all of the Unix
> MPMs, because we will finally be able to stop re-inserting the same
> socket into the pollset for every request.
> 
> Does anybody have a problem with this plan?  I would like to commit late
> this evening, which will give me enough time to fix Windows tonight
> (hopefully).
> 
> Ryan
> 

+1
Cheers,
-Thom
-- 
Thom May -> [EMAIL PROTECTED]

"Historically speaking, the presences of wheels in Unix
 has never precluded their reinvention." - Larry Wall

Re: Auth - how much legacy to preserve ?

[dirkx]

On Wed, 10 Jul 2002, Pier Fumagalli wrote:

> Dirk, since you're working on a patch for Auth, would it be possible to have
> the groups list somewhere in the request structure? It would be great with
> web applications, where we can match groups with roles (therefore allowing
> authentication to be processed by apache entirely)...

Well - r->user, or any r->credentials are valid there; as they come from
the protocol; i.e. are part of the request.

The group information can, depending on protocol, come from more than one
source

-> provided with the credentials (e.g. like the 'account'
   dimension in ftp or your kerberos realm).

-> a user can belong to N groups as returned by an
   all knowing auth system when asked.

-> a check if the user was in a list of M groups can have
   yieled that he was a member of P groups which is a
   subset of M.

Once you add group; there are other dimensions too; i.e. think of the
login.conf resources on BSD, a much more mature framework like that on
mainframes, and so on.

 So this is perhaps a bit more complex than just that.

What is it you would feel as most useful in the web application world -
could you elaborate ?

Dw.

Re: Port 80 vs 8080 when not SU.

[Thom May]

* Jim Jagielski ([EMAIL PROTECTED]) wrote :
> Ryan Bloom wrote:
> > 
> > We have fixed our installation step to preserve existing config files,
> > so if you compile as a non-root user, and install over the top of an
> > existing installation, your port won't change.
> > 
> > This only has to do with how the server is configured the FIRST time the
> > server is installed.
> > 
> 
> Which is the case with 1.3 as well, BTW.

It doesn't matter how many times it happens, or how many hysterical raisins
there are, it's still wrong behaviour.
We can't change options under someone just because their compilation
environment doesn't match our expectations. 
As Joshua says, this catches a lot of people out. We should put a warning in
the INSTALL file to point out you have to have root privs to attach to port
80, but we should not be changing anything that is runtime configurable 
unless the user explicitly asks for it.
Cheers,
-Thom
-- 
Thom May -> [EMAIL PROTECTED]

> Personally, I quite like the little pictures they display when things are
> scanned.  Just so you know what a zucchini looks like before you go
> throwing your money away on one.
"Oh shit! Is that zucchini? It said OREOS on the shelf!"

Re: Apache 2 instruction count profile (head as of ~15:00 EDT July10)

[Brian Pane]

Bill Stoddard wrote:

>Subroutine Name  Source File  Visit Enter  %   Ticks
>===  ===  = =  =
>.ap_rgetline_coreprotocol.c   366  1.5 709
>

Darn, all that optimization work and it's still at the top of the list.

>Shlib Subroutine Source File  Visit Enter  %   Ticks
> ===  = =  =
>.apr_palloc  apr_pools.c  7878 2.9 1404
>.__is_wctype_std libc/__is_wctype_std.c   6666 2.8 1320
>.apr_table_get   apr_tables.c 2117 2.6 1229
>.__divu64divu64.s 3 3  2.0 976
>.__divi64divi64.s 4 4  1.9 917
>.apr_table_setn  apr_tables.c 2412 1.6 781
>

Was this with the latest version of the apr_table code?  If so, I've
run out of ways to speed up apr_table_get() and apr_table_setn() without
changing the internal data structure used by the tables to something
that supports faster-than-O(n) lookups.

--Brian

Re: Auth checker - long term goal..

[Pier Fumagalli]

Ryan Bloom <[EMAIL PROTECTED]> wrote:

> I'm sorry, but that is completely bogus.  If the API needs to change to
> make things better, then change the API.  Stop trying to open a new dev
> branch when the current one is still moving forward quickly.  We have
> this discussion every few weeks now, and every few weeks the 2.1 repo
> gets shot down, because these changes belong in 2.0.

I tend to agree with Ryan although I'm no committer... Wouldn't want to see
httpd to end up like Tomcat did...

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]

Re: Auth - how much legacy to preserve ?

[Pier Fumagalli]

Dirk, since you're working on a patch for Auth, would it be possible to have
the groups list somewhere in the request structure? It would be great with
web applications, where we can match groups with roles (therefore allowing
authentication to be processed by apache entirely)...

Pier

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> 
> While doing this patch (and ending up with 3 very small modules); I found
> the following legacy behaviour. Any feels as to if we shall kill these
> surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:
> 
> ->if there are no requires - but there is Auth happening
> we actively OK.
> 
> -> If there are no requires for the method (but there are
> requires for that directory for other methods)
> we actively OK.
> 
> ->If we have for example a (Group,..)File but opening it failes
> then we ignore any 'require group' and DECLINE to other modules.
> 
> Proposal to fixing these leaks (comment now or wait for code) and allowing
> small footprint modules to take part of the process over:
> 
> ->mod_auth_file
> auth UserID/passwd against file
> DECLINE if no file configured
> ERRORif file read error (was DECLINE/UNAUTH)
> OKif ok
> DECLINE if UID not found & non-authoritative
> UNAUTHotherwise
> 
> ->mod_auth_groupfile
> checks UserID against required 'require (valid-)group'
> DECLINE if no requirements at all (was OK)
> DECLINE if no group file configurued
> ERROR   if file read error (was IGNORE)
> OKif in a group
> DECLINEif no applicable method requirments (was OK)
> DECLINE if no recognized method requirements
> DECLINE if not authoritative and not in recognized groups.
> UNAUTH otherwsie
> 
> ->mod_require_user
> checks UserID against required 'require (valid-)user'
> DECLINE if no requirements at all (was OK)
> OK if in the list /valid user
> DECLINE if no applicable method requirements. (was OK)
> DECLINE if no recognized requirements
> DECLINE if there are lists, not in list but non
> authoritative
> UNAUTH   otherwise
> 
> And then - to get closer to the old apache:
> 
> ->mod_auth_default
> auth DECLINEif no Basic Auth header/r->user.
> DECLINE if not authoritative
> UNAUTH otherwise
> 
> checkDECLINEif no r->user
> OK if no requires (*)
> OK if no applicable method requirements (*)
> DECLINEif not authoriative
> UNAUTHotherwise
> 
> *: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from
> 1.3;  An alternative would be to not do this and change to always UNAUTH
> then when there is r->user information provided and not authoritative.
> 
> I do want to allow fall through - so that a perl/php/java backend is able
> to get access if/when needed. Thus:
> 
> ->apache core
> authOK
> checkOK
> 
> Of course - the mod_auth_default could also be in the core of the http
> proocol handling.
> 
> Does this make sense ?
> 
> Dw.

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]

RE: Apache 2 instruction count profile (head as of ~15:00 EDT July 10)

[Ryan Bloom]

> From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
> 
> This is with Ryan's poll patch and some of my patches to mod_cache and
> mod_mem_cache (which I will publish later on).  Unfortuanetely the
results
> are difficult to compare with earlier results because my test tree was
> just
> too polluted with patches for Ryan's patch to cleanly apply.  Still,
the
> overall direction is good (7.5% reduction in instruction count). The
> difference between Jeff's wait_for_timeout and Ryan's is noise in this
> comparison. However, I suspect the apr_poll() is better in general and
is
> contributing to the improvement.

Based on these numbers, I would like to commit the new apr_poll() today.
This is likely to break everything but Unix for a few days however.
Once the code is committed, there are some obvious performance
improvements that can still be made.  The first, is to use a static
array for small poll sets, or use alloca on systems that have it.  The
second is to go through Apache and remove the functions that used to
setup poll sets.  That will actually have an impact on all of the Unix
MPMs, because we will finally be able to stop re-inserting the same
socket into the pollset for every request.

Does anybody have a problem with this plan?  I would like to commit late
this evening, which will give me enough time to fix Windows tonight
(hopefully).

Ryan

Re: "blank" Content-Length with Apache 2.0?

[William A. Rowe, Jr.]

I'm sort of dubious on the whole 'retain blank headers' bit.  If we put
them into the request_headers list, many modules might barf when
they encounter them.

Is it possible, by the protocol, to consider blank headers a noop,
and simply not store them in the request headers array?
E.g. no value [excepting white space] == not present?

Bill

At 02:40 PM 7/10/2002, you wrote:
>Should we also allow "blank" Content-Length headers in 2.0?
>
>Even if not, it seems to me that in the normal case, we're subjecting
>each "char" in the C-L: value field to at least one check before we
>go ahead and determine the real value. It appears more efficient to me
>to go ahead and simply use strtol and handle the error condition of a
>negative number when we check for errno (as we do with 1.3). This makes
>the normal condition more streamlined and slightly faster.
>--
>===
>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

Apache 2 instruction count profile (head as of ~15:00 EDT July 10)

[Bill Stoddard]

This is with Ryan's poll patch and some of my patches to mod_cache and
mod_mem_cache (which I will publish later on).  Unfortuanetely the results
are difficult to compare with earlier results because my test tree was just
too polluted with patches for Ryan's patch to cleanly apply.  Still, the
overall direction is good (7.5% reduction in instruction count). The
difference between Jeff's wait_for_timeout and Ryan's is noise in this
comparison. However, I suspect the apr_poll() is better in general and is
contributing to the improvement.

use ab to generate the test load: ab -k -n 10 -c 1 host/500bytefile.html

Here is the old (lots of patches):
Space  %Ticks
=   =
User  19.8  10304
Shared Library54.1  28107
Kernel26.0  13506

Total   51917



Here is the latest:
Space  %Ticks
=   =
User  18.4  8850
Shared Library53.3  25557
Kernel28.3  13569

Total   47976

/usr/local/apachetest/bin/httpd :

Subroutine Name  Source File  Visit Enter  %   Ticks
===  ===  = =  =
.ap_rgetline_coreprotocol.c   366  1.5 709
.get_filter_handle   util_filter.c2 2  1.2 591
.core_input_filter   core.c   237  1.1 513
.add_any_filter_handle   util_filter.c126  1.0 478
.fix_hostnamevhost.c  401  0.9 446
.core_output_filter  core.c   162  0.8 405
.net_time_filter core.c   248  0.8 395
.ap_get_mime_headers_core protocol.c  161  0.6 302
.add_any_filter  util_filter.c1 1  0.5 257
.ap_getword_whiteutil.c   282  0.5 254
._ptrgl  ptrgl.s  4242 0.5 252
.ap_find_token   util.c   5 3  0.5 229
.ap_get_brigade  util_filter.c3417 0.5 221
.ap_recent_rfc822_date   util_time.c  151  0.4 190
._moveeq moveeq.s 1010 0.4 185
.ap_content_length_filter protocol.c  6 1  0.3 158
.ap_set_keepalivehttp_protocol.c  121  0.3 148
.ap_read_request protocol.c   201  0.3 144
.isspace glink.s  2222 0.3 132
.apr_palloc  glink.s  2222 0.3 132
.read_request_line   protocol.c   111  0.3 125
.ap_pass_brigade util_filter.c105  0.3 121
.log_error_core  log.c4 4  0.3 120
.isalpha glink.s  1919 0.2 114
.tolower glink.s  1919 0.2 114
.ap_http_filter  http_protocol.c  8 2  0.2 99
.ap_log_errorlog.c8 4  0.2 88
.basic_http_header   http_protocol.c  131  0.2 84
.ap_update_child_status_from_indexes scoreboard.c 2 2  0.2 80
.form_header_field   http_protocol.c  102  0.2 78
.apr_table_get   glink.s  1212 0.2 72
.ap_discard_request_body http_protocol.c  4 1  0.1 71
.cached_explode  util_time.c  5 1  0.1 65
.core_create_req core.c   5 1  0.1 58
.apr_brigade_write   glink.s  8 8  0.1 48
.ap_run_create_request   request.c3 1  0.1 45
.writev_it_all   core.c   2 1  0.1 45
.check_pipeline_flushhttp_request.c   5 1  0.1 44
.ap_parse_uriprotocol.c   3 1  0.1 44
.basic_http_header_check http_protocol.c  3 1  0.1 42
.apr_setsocketoptglink.s  7 7  0.1 42
.apr_brigade_cleanup glink.s  7 7  0.1 42
.http_create_request http_core.c  4 1  0.1 38
.apr_table_make  glink.s  6 6  0.1 36
.apr_brigade_split_line  glink.s  6 6  0.1 36
.apr_brigade_create  glink.s  6 6  0.1 36
.ap_process_http_connection http_core.c   5 0  0.1 35
.ap_run_post_read_request protocol.c  2 1  0.1 34
.ap_run_log_transaction  protocol.c   2 1  0.1 33
.ap_set_byterange

Re: Port 80 vs 8080 when not SU.

[Jim Jagielski]

Who woudda thunk that such a minor thing would cause such a big
discussion :) I love open source collaboration.
-- 
===
   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: Port 80 vs 8080 when not SU.

[Aaron Bannert]

On Wed, Jul 10, 2002 at 12:30:35PM -0700, Joshua Slive wrote:
> ... The only people it helps are people who
> install apache often for testing, and these people should know to use
> --port on the configure command line.

Oh don't get me started on that again... ;)

-aaron

RE: Port 80 vs 8080 when not SU.

[Sander Striker]

> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: 10 July 2002 21:24

>> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
>> On Wed, Jul 10, 2002 at 03:12:07PM -0400, Jim Jagielski wrote:
>>> Have there been any complaints about how 1.3 has been doing it for
>>> ages? A 'make install; /bin/apachectl start' no matter who does
>>> the building has "always" resulted in at least a somewhat functional
>>> server. I don't see the reason for stopping a traditional behavior
>>> (and a possible expectation from the community) without more
>>> compelling reasons.
>> 
>> On the contrary, I don't believe we have an obligation to follow
>> 1.3 here.  I think what we are doing for 2.0 makes the most sense.
>> 
>> The default is the default.  Please don't muddle things based on
>> who is compiling it.  -- Justin
> 
> While I agree that changing the port based on the user who is compiling
> the server is a bit backwards, the argument about how things are done on
> Nagoya is handwaving IMNSHO.

*grin* I've got my hands on the keyboard now.
 
> We have fixed our installation step to preserve existing config files,
> so if you compile as a non-root user, and install over the top of an
> existing installation, your port won't change.
> 
> This only has to do with how the server is configured the FIRST time the
> server is installed.

*curses to self*.  Okay, in that case let's say I just don't like us messing
with the defaults based on the user doing the compiling.

> Ryan

Sander

"blank" Content-Length with Apache 2.0?

[Jim Jagielski]

Should we also allow "blank" Content-Length headers in 2.0?

Even if not, it seems to me that in the normal case, we're subjecting
each "char" in the C-L: value field to at least one check before we
go ahead and determine the real value. It appears more efficient to me
to go ahead and simply use strtol and handle the error condition of a
negative number when we check for errno (as we do with 1.3). This makes
the normal condition more streamlined and slightly faster.
-- 
===
   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: Port 80 vs 8080 when not SU.

[Sander Temme]

>> Have there been any complaints about how 1.3 has been doing it for
>> ages?
> 
> Yes.  I've seen many confused people posting to
> comp.infosystems.www.servers.unix who where caught by exactly this issue.
> It usually starts with a basic query like "I installed apache and it says
> that it started successfully, but I can't access it."  This is VERY
> difficult to debug, because it could be caused by any number of things.
> On the other hand, the problem report "I tried to start apache, but the
> error log says permission denied binding to port 80" is trivial to debug.

I agree. I have been bitten by this a long time ago before I knew what was
going on. I favor leaving this feature out of the 2.0 build process.

S.

-- 
Covalent Technologies [EMAIL PROTECTED]
Engineering groupVoice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105

   PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03  5531 AFB1 96AF B584 0AB1

===
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
===

Re: Port 80 vs 8080 when not SU.

[Thomas Eibner]

On Wed, Jul 10, 2002 at 12:30:35PM -0700, Joshua Slive wrote:
> As I've said, this "cute" feature is confusing for newbies and irritating
> for some legitimate users.  The only people it helps are people who
> install apache often for testing, and these people should know to use
> --port on the configure command line.

Yeah, or have a seperate config file they use specifically for their
testing. 

-- 
  Thomas Eibner 

Re: Port 80 vs 8080 when not SU.

[Cliff Woolley]

On Wed, 10 Jul 2002, Joshua Slive wrote:

> Yes.  I've seen many confused people posting to
> comp.infosystems.www.servers.unix who where caught by exactly this
> issue. It usually starts with a basic query like "I installed apache and
> it says that it started successfully, but I can't access it."  This is
> VERY difficult to debug, because it could be caused by any number of
> things. On the other hand, the problem report "I tried to start apache,
> but the error log says permission denied binding to port 80" is trivial
> to debug.

I agree.  +1 to leaving it out.  -0 to putting it back in.  Consistency is
a good thing... where in this case that means I think it should always
install on the same port regardless of uid and all.  Historical
consistency takes the backburner for the reasons Joshua mentioned.

--Cliff

Re: Port 80 vs 8080 when not SU.

[Joshua Slive]

On Wed, 10 Jul 2002, Jim Jagielski wrote:

> Have there been any complaints about how 1.3 has been doing it for
> ages?

Yes.  I've seen many confused people posting to
comp.infosystems.www.servers.unix who where caught by exactly this issue.
It usually starts with a basic query like "I installed apache and it says
that it started successfully, but I can't access it."  This is VERY
difficult to debug, because it could be caused by any number of things.
On the other hand, the problem report "I tried to start apache, but the
error log says permission denied binding to port 80" is trivial to debug.

> A 'make install; /bin/apachectl start' no matter who does
> the building has "always" resulted in at least a somewhat functional
> server.

I don't see how the server can be considered functional when there is no
way to know how to access it.  How do you figure out the correct URL?  The
only way to do that is to look in the config file for the Port, and if you
know enough to do that, you surely know enough to change that port
yourself.

As I've said, this "cute" feature is confusing for newbies and irritating
for some legitimate users.  The only people it helps are people who
install apache often for testing, and these people should know to use
--port on the configure command line.

Joshua.

RE: Port in Makefile.in

[Ryan Bloom]

You are.  That's because we used to do the PORT replacement based on
uid.  Hm.  If I had caught that when I removed Port, this discussion
would never have happened.

That is enough reason in my mind to add the feature back in.

Ryan

> We still seem to be pretending we have a Port directive in Apache 2.0.
> There's a superfluous -e 's#@@Port@@#$(PORT)#g' handling of the config
> files, if I'm reading Makefile.in right.

Port in Makefile.in

[Jim Jagielski]

We still seem to be pretending we have a Port directive in Apache 2.0.
There's a superfluous -e 's#@@Port@@#$(PORT)#g' handling of the config
files, if I'm reading Makefile.in right.
-- 
===
   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: Port 80 vs 8080 when not SU.

[Jim Jagielski]

Ryan Bloom wrote:
> 
> We have fixed our installation step to preserve existing config files,
> so if you compile as a non-root user, and install over the top of an
> existing installation, your port won't change.
> 
> This only has to do with how the server is configured the FIRST time the
> server is installed.
> 

Which is the case with 1.3 as well, BTW.
-- 
===
   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: Port 80 vs 8080 when not SU.

[Ryan Bloom]

> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> 
> On Wed, Jul 10, 2002 at 03:12:07PM -0400, Jim Jagielski wrote:
> > Have there been any complaints about how 1.3 has been doing it for
> > ages? A 'make install; /bin/apachectl start' no matter who does
> > the building has "always" resulted in at least a somewhat functional
> > server. I don't see the reason for stopping a traditional behavior
> > (and a possible expectation from the community) without more
> > compelling reasons.
> 
> On the contrary, I don't believe we have an obligation to follow
> 1.3 here.  I think what we are doing for 2.0 makes the most sense.
> 
> The default is the default.  Please don't muddle things based on
> who is compiling it.  -- Justin

While I agree that changing the port based on the user who is compiling
the server is a bit backwards, the argument about how things are done on
Nagoya is handwaving IMNSHO.

We have fixed our installation step to preserve existing config files,
so if you compile as a non-root user, and install over the top of an
existing installation, your port won't change.

This only has to do with how the server is configured the FIRST time the
server is installed.

Ryan

Re: Port 80 vs 8080 when not SU.

[Jim Jagielski]

Justin Erenkrantz wrote:
> 
> On Wed, Jul 10, 2002 at 03:12:07PM -0400, Jim Jagielski wrote:
> > Have there been any complaints about how 1.3 has been doing it for
> > ages? A 'make install; /bin/apachectl start' no matter who does
> > the building has "always" resulted in at least a somewhat functional
> > server. I don't see the reason for stopping a traditional behavior
> > (and a possible expectation from the community) without more
> > compelling reasons.
> 
> On the contrary, I don't believe we have an obligation to follow
> 1.3 here.  I think what we are doing for 2.0 makes the most sense.
> 
> The default is the default.  Please don't muddle things based on
> who is compiling it.  -- justin
> 

It's not just who is compiling it, but who is installing it, I thought.
As long as it's a documented change from how 1.3 does things, it's
really a minor point :)

 +0

-- 
===
   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: Port 80 vs 8080 when not SU.

[dirkx]

On Wed, 10 Jul 2002, Jim Jagielski wrote:

> Have there been any complaints about how 1.3 has been doing it for

None seen here.

> ages? A 'make install; /bin/apachectl start' no matter who does
> the building has "always" resulted in at least a somewhat functional
> server. I don't see the reason for stopping a traditional behavior
> (and a possible expectation from the community) without more
> compelling reasons.

The reason I brought it up was that I've noticed an increase in the
'cannot bind to port...' errors on some company lists I follow. Something
I had not seen anyone complain about in years and years.

Dw.

Re: proxy debug messages and passwords :)

[Graham Leggett]

Jeff Trawick wrote:

> Maybe proxy should contruct a printable URL for use in debug messages,
> where the optional password has been replaced with ? or some other
> character?

I think proxy did at one stage, I recall seeing a function in there to 
strip passwords out. Will take a look in the next day or two (drowning 
in panic).

Regards,
Graham
-- 
-
[EMAIL PROTECTED] 
"There's a moon
over Bourbon Street
tonight..."

Re: Port 80 vs 8080 when not SU.

[Justin Erenkrantz]

On Wed, Jul 10, 2002 at 03:12:07PM -0400, Jim Jagielski wrote:
> Have there been any complaints about how 1.3 has been doing it for
> ages? A 'make install; /bin/apachectl start' no matter who does
> the building has "always" resulted in at least a somewhat functional
> server. I don't see the reason for stopping a traditional behavior
> (and a possible expectation from the community) without more
> compelling reasons.

On the contrary, I don't believe we have an obligation to follow
1.3 here.  I think what we are doing for 2.0 makes the most sense.

The default is the default.  Please don't muddle things based on
who is compiling it.  -- justin

Re: Port 80 vs 8080 when not SU.

[Jim Jagielski]

Have there been any complaints about how 1.3 has been doing it for
ages? A 'make install; /bin/apachectl start' no matter who does
the building has "always" resulted in at least a somewhat functional
server. I don't see the reason for stopping a traditional behavior
(and a possible expectation from the community) without more
compelling reasons.

-- 
===
   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: OpenBSD/separation of priv's

[dirkx]

On Wed, 10 Jul 2002, Bill Stoddard wrote:

> > What Theo is after with Monolithic is just the current fad-du-jour;
...
> I had to laugh at the 'fad-du-jour' comment. This is very old hat with the
> IBM OS/390 crowd. They've been doing that since the time the birds and trees

L'Histoire se repete :-) As fashions do :-).

Dw

RE: Port 80 vs 8080 when not SU.

[Sander Striker]

> From: Thom May [mailto:[EMAIL PROTECTED]]
> Sent: 10 July 2002 18:04

> * Jim Jagielski ([EMAIL PROTECTED]) wrote :
> > Thom May wrote:

> Please don't do this. We should_not_ be second guessing the user.
>
> > I'd prefer education but also that they get a configuration that they
> > can test "right after" a build/install :)
> >
> How do you know they are not doing what I do:
> configure; build and install as thom
> run as root.

Exactly.  Actually, this is how we are setup on nagoya.  All admins are
in the same group and configure/compile/install using their own account.

> There is a perfectly good configure option to change the port, if they want
> the port changed the user should use that.
> A config system should not alter configs away from the default unless the
> user specifically requests it.
> If we do this I'm sure we'll see an awful lot of PRs cropping up of the
> form:
> "started apache but it is not listening on http://localhost/";
>
> This is a non-commiter's -1, then.

Sander

Re: [PATCH] Patch to compile apache-1.3.20+ on LynxOS-3.0.1

[Jim Jagielski]

The patches look acceptable, except for the below... Why the change?
'-depth' not supported in LynxOS's find?

At 1:51 PM +0200 7/10/02, Fulvio Bille` wrote:
>Hi,
>this patch enable to run configure and compile on LynxOS-3.0.1
>Any source file is modified.
>Only Configure, GuessOS, mkshadow.sh and ap_config.h are modified.
>Bye.
>
>--- ./src/helpers/mkshadow.sh Tue Jun 29 15:43:15 1999
>+++ ../apache_1.3.26-patched/src/helpers/mkshadow.sh Fri Jul  5 14:11:19
>
>2002
>@@ -65,7 +65,7 @@
>
> #   fill directory tree with symlinks to files
> FILES="`cd $src; \
>-find . -depth -print |\
>+find . -print |\
> sed -e '/\.o$/d' \
> -e '/\.a$/d' \
> -e '/\.so$/d' \
>diff -ruN ./src/include/ap_config.h
>../apache_1.3.26-patched/src/include/ap_config.h

-- 
===
   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: OpenBSD/separation of priv's

[Bill Stoddard]

> What Theo is after with Monolithic is just the current fad-du-jour;
> separation of priv's like recently done in SSH.
>
> Our MPM's are a very cool starting point.
>
> Dw
>
> --
> Dirk-Willem van Gulik
>

I had to laugh at the 'fad-du-jour' comment. This is very old hat with the
IBM OS/390 crowd. They've been doing that since the time the birds and trees
were one with man :-). For some applications (and admins) this is a very big
deal. Rasmus has referred to them as 'extreme high end' users. And yes, the
MPM is a great starting point for providing these types of services in the
HTTP Server (not that we should... it does come at a price.).

Bill

Re: Auth checker - long term goal..

[Aaron Bannert]

On Wed, Jul 10, 2002 at 11:19:31AM -0700, Brian Pane wrote:
> From my perspective, the event that should cause us to branch for
> a 2.1 or 3.0 release isn't "this code change is too drastic for 2.0"
> but rather: "this new feature that's useful to customers is impossible
> to build or maintain on top of the 2.0 framework."  And hopefully it
> will be a while before we get to that point: 2.0's design allows us
> to make a *lot* of changes without requiring a rearchitecture of the
> core server.
> 
> I'd really like to see a roadmap that says something like:
> 
>  Remaining 2.0 maintenance releases:
>- Incremental performance improvements
>- Bug fixes
>- New modules and MPMs as needed
> 
>  2.1:
>- "Sandbox" processes in which to run untrusted plug-in code safely
>- Further refactoring of the core daemon to make it easier
>  to support non-HTTP protocols
> 
>  3.0:
>- New architecture for massive scalability

I disagree, but not strongly. The reason I don't like the idea of a strict
roadmap of features is because it has the tendency to place restrictions
on what people can work on, and that isn't The Apache Way.  The ad-hoc
posting of patches and acceptance of those units of work has a great
benefit in our volunteer community. If the roadmap is simply a list of
cool things we'd like to add, and where some of the developers think
the project is going, then it can be encouraging for new development.
As soon as it becomes a tool to ban features from being incorporated
into the tree, it will discourage spontaneous volunteerism. I'd much
rather see the roadmap as our collective brainstorm.

In other words, we should just keep going, looking at one patch at
a time, and as soon as someone takes the reigns and produces something
revolutionary that we aren't quite ready to force onto our 2.0 users,
then it may be time to think about a branch.

-aaron

Auth - how much legacy to preserve ?

[dirkx]

While doing this patch (and ending up with 3 very small modules); I found
the following legacy behaviour. Any feels as to if we shall kill these
surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:

->  if there are no requires - but there is Auth happening
we actively OK.

->  If there are no requires for the method (but there are
requires for that directory for other methods)
we actively OK.

->  If we have for example a (Group,..)File but opening it failes
then we ignore any 'require group' and DECLINE to other modules.

Proposal to fixing these leaks (comment now or wait for code) and allowing
small footprint modules to take part of the process over:

->  mod_auth_file
auth UserID/passwd against file
DECLINE if no file configured
ERROR   if file read error (was DECLINE/UNAUTH)
OK  if ok
DECLINE if UID not found & non-authoritative
UNAUTH  otherwise

->  mod_auth_groupfile
checks UserID against required 'require (valid-)group'
DECLINE if no requirements at all (was OK)
DECLINE if no group file configurued
ERROR   if file read error (was IGNORE)
OK  if in a group
DECLINE if no applicable method requirments (was OK)
DECLINE if no recognized method requirements
DECLINE if not authoritative and not in recognized groups.
UNAUTH otherwsie

->  mod_require_user
checks UserID against required 'require (valid-)user'
DECLINE if no requirements at all (was OK)
OK if in the list /valid user
DECLINE if no applicable method requirements. (was OK)
DECLINE if no recognized requirements
DECLINE if there are lists, not in list but non
authoritative
UNAUTH   otherwise

And then - to get closer to the old apache:

->  mod_auth_default
authDECLINE if no Basic Auth header/r->user.
DECLINE if not authoritative
UNAUTH  otherwise

check   DECLINE if no r->user
OK  if no requires (*)
OK  if no applicable method requirements (*)
DECLINE if not authoriative
UNAUTH  otherwise

*: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from
1.3;  An alternative would be to not do this and change to always UNAUTH
then when there is r->user information provided and not authoritative.

I do want to allow fall through - so that a perl/php/java backend is able
to get access if/when needed. Thus:

->  apache core
authOK
check   OK

Of course - the mod_auth_default could also be in the core of the http
proocol handling.

Does this make sense ?

Dw.
-- 
Dirk-Willem van Gulik

Re: Auth checker - long term goal..

[Brian Pane]

Aaron Bannert wrote:

>On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
>  
>
>>I still believe that everything that is currently in ROADMAP can and
>>should be implemented in 2.0.
>>

I agree.

>And my point is we won't know until there is a patch that solves
>one of the roadmap problems. Only then will we be able to decide.
>

The problem I have with the roadmap is that it's mostly a list
of implementation changes.  What it should be is a list of product
features: things that are meaningful to a customer of Apache (whether
that customer is an end-user or a third-party developer), not just
meaningful to those of us who work on the httpd code.

 From my perspective, the event that should cause us to branch for
a 2.1 or 3.0 release isn't "this code change is too drastic for 2.0"
but rather: "this new feature that's useful to customers is impossible
to build or maintain on top of the 2.0 framework."  And hopefully it
will be a while before we get to that point: 2.0's design allows us
to make a *lot* of changes without requiring a rearchitecture of the
core server.

I'd really like to see a roadmap that says something like:

  Remaining 2.0 maintenance releases:
- Incremental performance improvements
- Bug fixes
- New modules and MPMs as needed

  2.1:
- "Sandbox" processes in which to run untrusted plug-in code safely
- Further refactoring of the core daemon to make it easier
  to support non-HTTP protocols

  3.0:
- New architecture for massive scalability

--Brian

Re: Auth checker - long term goal..

[William A. Rowe, Jr.]

At 12:56 PM 7/10/2002, Aaron Bannert wrote:
>On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
> > I still believe that everything that is currently in ROADMAP can and
> > should be implemented in 2.0.
>
>And my point is we won't know until there is a patch that solves
>one of the roadmap problems. Only then will we be able to decide.

EXACTLY!

If someone offers a patch to split various authn/authz hooks, while
retaining the existing hooks so that 3rd parties don't -need- to adopt
the new features, then terrific.

And if we like, we can mark the old methods as deprecated and soon
to disappear in 2.1.

Bill

Re: [PATCH] mpm/winnt service permissions

[William A. Rowe, Jr.]

At 12:54 PM 7/10/2002, you wrote:
>  That's the responsibility of Windows.  By forcing admin privileges to call
>apache -k * isn't creating any kind of security.  Anybody could create a 
>simple
>five like program or open up services from the control panel to control apache
>if their account has the rights to do so.  Just because apache.exe and AM 
>forces
>admin requirements, the system does not.
>
>But I think I see what you're saying and to enforce that we'd need to add 
>account
>checking to the startup code, not the service control code.

We aren't enforcing anything.

What we've tried to do is to assure that AM and apache -k foo will do what they
are -allowed- to do under the user's current permissions, crippling only 
the features
that the user is -denied-.

So if the Apache service is set up to run as effectively nobody, it won't 
be fixing
the service 'Description' to the server string.  Big deal.  That shouldn't 
mean it
fails, only that the one feature can't be supported [and we should continue.]

Apache can and does only does what it's allowed to do.

Bill

Re: Auth checker - long term goal..

[Aaron Bannert]

On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
> I still believe that everything that is currently in ROADMAP can and
> should be implemented in 2.0.

And my point is we won't know until there is a patch that solves
one of the roadmap problems. Only then will we be able to decide.

-aaron

Re: The word on: adding modules

[Harrie Hazewinkel]

HI,

I am probably not speaking for most of the modules. I have been doing
patching of Apache forever, since otherwise certain 
information/functionality
from Apache cannot be done in an SNMP managed way by MOD-SNMP.



Harrie
--On Wednesday, July 10, 2002 12:26 PM +0200 [EMAIL PROTECTED] wrote:

>
> Right now, as devlopers, we have a whole range of methods of adding in a
> module; from hacking it in, copying it into an existing modules/*
> directory (e.g.  auth, mappers), APXS all the way, down to its own
> directory with a little config.m4.
>
> When documenting 'How to add your modules to apache 2.0' what should be
> official word - i.e. what do we want the instructions on a random
> modules.apache.org or sourceforge module to say:
>
>   1.  APXS prefered
>
>   apxs -c mod_foo.c bar.c comms.c
>

I would think that the most prefered method could be APXS.
WHy do I think this??

1)
For most users it is simple to do:
./configure --enable-module=so ; make ; make install
Followed by building a module with APXS.


2)
On some systems their is now an Apache already available and thus also
APXS. On those systems an user adding a module can easily use APXS
without any fiddling in Apache code/directories.

> Or, if you need it,
>
>   2.  module/foo directory with Makefile.in/config.m4

This would always require a user to compile a module with compiling
Apache as well. APXS could avoid this, if he can retrieve binaries
somewhere else of Apache (like is provided by some companies)

>
> as to allow more Configure(ation) also for the simple case ? I am looking
> for 'the word' :-) as right now the 1.3 situation is messy: dso, static,
> apxs, hack modules,c - and would like to some more guidance for 2.0.
>
> Opinions ? Fears ?


OK, the above opinion does not mean that I think patching should not
be done to the apache core. From a viewpoint of MOD-SNMP, I still
will do it, unless some parts of the code will be made in such a
way that modules can dynamically change/tune the configuration
without restarting the server.

(This is not ment to start discussing dynamic configuration without
restarting, since I know that manye of you oppose this anyway.
With or without good reasoning from those.)



Harrie

Internet Management Consulting
mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
---
Author of MOD-SNMP, enabling SNMP management to the Apache server.

Re: [PATCH] mpm/winnt service permissions

[David Shane Holden]

  That's the responsibility of Windows.  By forcing admin privileges to 
call
apache -k * isn't creating any kind of security.  Anybody could create a 
simple
five like program or open up services from the control panel to control 
apache
if their account has the rights to do so.  Just because apache.exe and 
AM forces
admin requirements, the system does not.

But I think I see what you're saying and to enforce that we'd need to 
add account
checking to the startup code, not the service control code.

Shane


Mladen Turk wrote:

>Just one thought :-)
>
>I think that at least Administrator privileges are needed to start the
>services. 
>The ApacheMonitor will definitely need that once when async behavior
>will be used, so that calls for starting services gets serialized with
>LockServiceDatabase that needs Admin privileges.
>So I'm for the GENERIC_READ/GENERIC_WRITE/GENERIC_EXECUTE generic access
>types, and not for finding security holes. Neither AM nor Apache
>shouldn't brake that allowing starting or stopping something that cannot
>be done through Service Manager itself, and should report that as access
>violation errors.
> 
>MT.
>
>  
>
>>-Original Message-
>>From: David Shane Holden [mailto:[EMAIL PROTECTED]] 
>>Sent: Wednesday, July 10, 2002 2:28 AM
>>To: [EMAIL PROTECTED]
>>Subject: Re: [PATCH] mpm/winnt service permissions
>>
>>
>>Correct me if I'm wrong, but it sounds like you think this is for 
>>ApacheMonitor.  This is for the winnt mpm itself.
>>I thought your patch this morning was for the mpm just as I 
>>believe you 
>>think this is for the monitor.
>>
>>Shane
>>
>>
>>William A. Rowe, Jr. wrote:
>>
>>
>>
>>>At 01:40 PM 7/9/2002, you wrote:
>>>
>>>  
>>>
This patch sets the calls to OpenSCManager and OpenService 


>>to use the
>>
>>
minimum required privileges.


>>>Cool.  Could you cvs up to grab the latest version with Mladen's 
>>>patch, compare your suggested changes to his latest changes for 
>>>requested privileges, and provide an updated patch to discuss?
>>>
>>>Bill
>>>
>>>  
>>>
>
>  
>
- SC_MANAGER_ALL_ACCESS);
+ SC_MANAGER_CONNECT);
 if (!schSCManager) {
 rv = apr_get_os_error();
 ap_log_error(APLOG_MARK, APLOG_ERR | 


>>APLOG_STARTUP, rv,
>>
>>
NULL,
@@ -1265,7 +1262,7 @@
 SC_HANDLE   schSCManager;

 schSCManager = OpenSCManager(NULL, NULL, // 


>>default machine
>>
>>
& database
- SC_MANAGER_ALL_ACCESS);
+ SC_MANAGER_CONNECT);

 if (!schSCManager) {
 ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_STARTUP,
apr_get_os_error(), NULL,
@@ -1275,7 +1272,8 @@

 /* ###: utf-ize */
 schService = OpenService(schSCManager, mpm_service_name,
- SERVICE_ALL_ACCESS);
+ SERVICE_INTERROGATE |
SERVICE_QUERY_STATUS |
+ SERVICE_START | SERVICE_STOP);

 if (schService == NULL) {
 /* Could not open the service */


>>>  
>>>
>>
>>
>
>  
>

OpenBSD/separation of priv's

[dirkx]

What Theo is after with Monolithic is just the current fad-du-jour;
separation of priv's like recently done in SSH.

Our MPM's are a very cool starting point.

Dw

-- 
Dirk-Willem van Gulik

RE: Auth checker - long term goal..

[Ryan Bloom]

I still believe that everything that is currently in ROADMAP can and
should be implemented in 2.0.

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

> -Original Message-
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 10, 2002 10:37 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Auth checker - long term goal..
> 
> At 12:07 PM 7/10/2002, Aaron Bannert wrote:
> >On Wed, Jul 10, 2002 at 09:39:29AM -0700, Ryan Bloom wrote:
> > > I'm sorry, but that is completely bogus.  If the API needs to
change
> to
> > > make things better, then change the API.  Stop trying to open a
new
> dev
> > > branch when the current one is still moving forward quickly.  We
have
> > > this discussion every few weeks now, and every few weeks the 2.1
repo
> > > gets shot down, because these changes belong in 2.0.
> >
> >I don't recall any strong opinions on this other than from you and
> >OtherBill.
> >
> >My feeling is somewhere between. We shouldn't rush off and branch 2.1
if
> >we don't have any specific goals to solve, nor should we be forcing
major
> >changes upon our 2.0 users. The point of inflection comes when
someone
> >produces a patch for 2.0 that we aren't quite ready to swallow. As
soon
> >as that happens we have a perfect excuse for a branch.
> 
> The list is in ROADMAP.  Every item there was effectively vetoed for
the
> current development tree as too radical an overhaul.  Each was pointed
to
> "the next version, we are {too close to|already for|already have the
ga}
> release".
> Improve the ROADMAP.  Spell out what 2.1/3.0 will offer.
> 
> Things like needing to track r->openfile instead of r->filename,
needing
> to
> follow a new convention to write auth modules {splitting authn/authz
into
> smaller useful chunks, but with no back-compat}, proving pushback as a
> more effective authoring and performance filtering model (that
accomodates
> both input and output filters in the same schema), async
cross-threaded
> requests, and so forth.
> 
> >S -1 for 2.1 until we have such a patch.
> 
> I agree we aren't ready for 2.1 until 2.0 is stable and relatively bug
> free.
> I thought someone a year and a half ago actually threw one out there
> for some of the auth, but I too want the group to stay focused on
making
> 2.0 a serious threat to 1.3 and other servers.  Without breaking
existing
> 3rd party modules beyond rebuilding, and occasional API changes, that
> are absolutely required.  API changes that break 3rd party 2.0
modules,
> just "because it's better|cooler|faster", are bogus now that we are
GA.
> 
> Bill
> 

Re: Auth checker - long term goal..

[William A. Rowe, Jr.]

At 12:07 PM 7/10/2002, Aaron Bannert wrote:
>On Wed, Jul 10, 2002 at 09:39:29AM -0700, Ryan Bloom wrote:
> > I'm sorry, but that is completely bogus.  If the API needs to change to
> > make things better, then change the API.  Stop trying to open a new dev
> > branch when the current one is still moving forward quickly.  We have
> > this discussion every few weeks now, and every few weeks the 2.1 repo
> > gets shot down, because these changes belong in 2.0.
>
>I don't recall any strong opinions on this other than from you and
>OtherBill.
>
>My feeling is somewhere between. We shouldn't rush off and branch 2.1 if
>we don't have any specific goals to solve, nor should we be forcing major
>changes upon our 2.0 users. The point of inflection comes when someone
>produces a patch for 2.0 that we aren't quite ready to swallow. As soon
>as that happens we have a perfect excuse for a branch.

The list is in ROADMAP.  Every item there was effectively vetoed for the
current development tree as too radical an overhaul.  Each was pointed to
"the next version, we are {too close to|already for|already have the ga} 
release".
Improve the ROADMAP.  Spell out what 2.1/3.0 will offer.

Things like needing to track r->openfile instead of r->filename, needing to
follow a new convention to write auth modules {splitting authn/authz into
smaller useful chunks, but with no back-compat}, proving pushback as a
more effective authoring and performance filtering model (that accomodates
both input and output filters in the same schema), async cross-threaded
requests, and so forth.

>S -1 for 2.1 until we have such a patch.

I agree we aren't ready for 2.1 until 2.0 is stable and relatively bug free.
I thought someone a year and a half ago actually threw one out there
for some of the auth, but I too want the group to stay focused on making
2.0 a serious threat to 1.3 and other servers.  Without breaking existing
3rd party modules beyond rebuilding, and occasional API changes, that
are absolutely required.  API changes that break 3rd party 2.0 modules,
just "because it's better|cooler|faster", are bogus now that we are GA.

Bill

Re: Auth checker - long term goal..

[Aaron Bannert]

On Wed, Jul 10, 2002 at 09:39:29AM -0700, Ryan Bloom wrote:
> I'm sorry, but that is completely bogus.  If the API needs to change to
> make things better, then change the API.  Stop trying to open a new dev
> branch when the current one is still moving forward quickly.  We have
> this discussion every few weeks now, and every few weeks the 2.1 repo
> gets shot down, because these changes belong in 2.0.

I don't recall any strong opinions on this other than from you and
OtherBill.

My feeling is somewhere between. We shouldn't rush off and branch 2.1 if
we don't have any specific goals to solve, nor should we be forcing major
changes upon our 2.0 users. The point of inflection comes when someone
produces a patch for 2.0 that we aren't quite ready to swallow. As soon
as that happens we have a perfect excuse for a branch.


S -1 for 2.1 until we have such a patch.

-aaron

RE: Auth checker - long term goal..

[Ryan Bloom]

> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 10, 2002 9:31 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Auth checker - long term goal..
> 
> At 11:22 AM 7/10/2002, Ryan Bloom wrote:
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > >
> > >
> > > On Wed, 10 Jul 2002, Ryan Bloom wrote:
> > >
> > > > >   user foo" checks. 'require group' can stay in mod_auth or
> > > > >   go into a mod_auth_group.
> > > >
> > > > Didn't we decide to take this approach like a year ago?
> > >
> > > Hmm - been asleep as usual - if so - I'd love to make that split
right
> > > away ! I feel a patch coming...
> >
> >I am pretty sure that splitting auth from authz is even listed in the
> >STATUS file.
> 
> It is in fact in the ROADMAP file.  See there.
> 
> Then feel free to decorate with more details.  I agree with Dirk, it's
> too much to ask all porters/module authors to rework their entire
> stratagem in the production branch.
> 
> It's time for 2.1.  We don't need to make .1 a total overhaul, simply
> address the things we've wanted for some time, that are likely to
> inflict new bugs on 3rd party modules.

I'm sorry, but that is completely bogus.  If the API needs to change to
make things better, then change the API.  Stop trying to open a new dev
branch when the current one is still moving forward quickly.  We have
this discussion every few weeks now, and every few weeks the 2.1 repo
gets shot down, because these changes belong in 2.0.

Ryan

RE: Auth checker - long term goal..

[William A. Rowe, Jr.]

At 11:22 AM 7/10/2002, Ryan Bloom wrote:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >
> >
> > On Wed, 10 Jul 2002, Ryan Bloom wrote:
> >
> > > >   user foo" checks. 'require group' can stay in mod_auth or
> > > >   go into a mod_auth_group.
> > >
> > > Didn't we decide to take this approach like a year ago?
> >
> > Hmm - been asleep as usual - if so - I'd love to make that split right
> > away ! I feel a patch coming...
>
>I am pretty sure that splitting auth from authz is even listed in the
>STATUS file.

It is in fact in the ROADMAP file.  See there.

Then feel free to decorate with more details.  I agree with Dirk, it's
too much to ask all porters/module authors to rework their entire
stratagem in the production branch.

It's time for 2.1.  We don't need to make .1 a total overhaul, simply
address the things we've wanted for some time, that are likely to
inflict new bugs on 3rd party modules.

Bill

Re: [PATCH] define proxy-specific hook macros

[William A. Rowe, Jr.]

At 07:29 AM 7/10/2002, you wrote:
>This defines macros similar to the AP_ counterparts in ap_config.h.  I
>was playing with a new proxy hook and optionally implementing the hook
>in a non-proxy module when I encountered the need to use APR_ hook
>macros to make it work.
>
>It would seem to be consistent and friendly to define these new PROXY_
>hook macros, but it is not absolutely required.

Nope, not required.  But we have grown quite a few hooks over in Proxy,
haven't we :-?

+1.

Bill

Re: Port 80 vs 8080 when not SU.

[Thom May]

* Jim Jagielski ([EMAIL PROTECTED]) wrote :
> Thom May wrote:
> > 
> > > How about an extra echo:
> > > 
> > > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > >   conf_port="8080"
> > >   echo "Non-root process. Server will run on port $conf_port"
> > > fi
> > 
> > I think the best solution is to educate the user, rather than to do
> > something unexpected.
> > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > echo "You are not currently the superuser. Therefore we can't start
> > apache listening on a privileged port (One above 1024)"
> > fi
> > 
> 
> Add to that the "Server will run..." message and the setting to port 8080
> and +1 :)
> 
Please don't do this. We should_not_ be second guessing the user.

> I'd prefer education but also that they get a configuration that they
> can test "right after" a build/install :)
>
How do you know they are not doing what I do:
configure; build and install as thom
run as root.

There is a perfectly good configure option to change the port, if they want
the port changed the user should use that. 
A config system should not alter configs away from the default unless the
user specifically requests it.
If we do this I'm sure we'll see an awful lot of PRs cropping up of the
form:
"started apache but it is not listening on http://localhost/";

This is a non-commiter's -1, then.

Cheers
-Thom

-- 
Thom May -> [EMAIL PROTECTED]

"Historically speaking, the presences of wheels in Unix
 has never precluded their reinvention." - Larry Wall

RE: Auth checker - long term goal..

[Sander Striker]

> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: 10 July 2002 18:15
> To: [EMAIL PROTECTED]
> Subject: RE: Auth checker - long term goal..
> 
> 
> 
> 
> > ->  Or alternatively mod_auth is split into a mod_auth and a
> > a mod_require. The first does the File based username
> > checking; the latter does the "require valid-user", "require
> > user foo" checks. 'require group' can stay in mod_auth or
> > go into a mod_auth_group.
> 
> Didn't we decide to take this approach like a year ago?

We did.  IIRC, we wanted to have the split before 2.0 was released.
There was something that held this change back.  Please check the
thread before committing anything.

Sander

Re: MacOS X 10.1.2 libtool

[Sander Temme]

> /foo/runtime/build/libtool: parse error: condition expected: xyes = [3183]

> But.. this does result in a functional module.

This is an issue with stock GNU libtool 1.4.2 on this platform. It affects
the binary file type of the linked module which would cause runtime breakage
on darwin until, I believe, the following commit to apr/dso/unix/dso.c:

> revision 1.49
> date: 2002/03/20 19:45:02;  author: rbb;  state: Exp;  lines: +25 -11
> Load libraries if they not MH_BUNDLE, but if they are not, it
> just attempts to link them as shared libs.  This is required to get
> the JVM loaded through APR.
> 
> Submitted by:   Pier Fumagalli <[EMAIL PROTECTED]>
> Reviewed by:Ryan Bloom

That's where we started to deal with both bundles and dylibs.

S.

-- 
Covalent Technologies [EMAIL PROTECTED]
Engineering groupVoice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105

   PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03  5531 AFB1 96AF B584 0AB1

===
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
===

RE: Auth checker - long term goal..

[Ryan Bloom]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> 
> On Wed, 10 Jul 2002, Ryan Bloom wrote:
> 
> > >   user foo" checks. 'require group' can stay in mod_auth or
> > >   go into a mod_auth_group.
> >
> > Didn't we decide to take this approach like a year ago?
> 
> Hmm - been asleep as usual - if so - I'd love to make that split right
> away ! I feel a patch coming...

I am pretty sure that splitting auth from authz is even listed in the
STATUS file.

Ryan

RE: Auth checker - long term goal..

[dirkx]

> > Ad **: Which of course would need another hook... and run method in
> > apache 3.0.
>
> There is no reason to wait for Apache 3.0 to add a new hook.  The whole
> reason for the hook abstraction was to make adding hooks painless for
> module authors.

Well - but this is a rather fundamental API change - at it would make the
require array out of bounds; i.e. it changes the way you would interact
wiht that array in a fairly fundamental way - and would make it more like
how want interacts with the command rec or general hook passing.

Dw

RE: Auth checker - long term goal..

[dirkx]

On Wed, 10 Jul 2002, Ryan Bloom wrote:

> > user foo" checks. 'require group' can stay in mod_auth or
> > go into a mod_auth_group.
>
> Didn't we decide to take this approach like a year ago?

Hmm - been asleep as usual - if so - I'd love to make that split right
away ! I feel a patch coming...

Dw

RE: Auth checker - long term goal..

[Ryan Bloom]

> ->Or alternatively mod_auth is split into a mod_auth and a
>   a mod_require. The first does the File based username
>   checking; the latter does the "require valid-user", "require
>   user foo" checks. 'require group' can stay in mod_auth or
>   go into a mod_auth_group.

Didn't we decide to take this approach like a year ago?

> With that out of the way; In the long term may want to do the same for
> groups checking which now fundamentally must happen in each module as
> group findings are not shared.
> 
> I.e. just like we have a r->user have a r->groups field (a table
rather
> than a char*) which lists the groups the user is part off. (Though I
> recognize that there will always be group auth modules which need to
to
> the reverse; i.e. check if a user is in a list of groups - or, for
these
> cases, an additional check_group_access handler mirroring the
user_access
> stage).
> 
> Any thoughds ? Note that part of the above problem is perception
causing
> the duplication of mod_auth because of the file association.
> 
> Dw
> --
> Dirk-Willem van Gulik
> 
> Ad *: We'd need to touch up the error messages of mod_auth a little.
> Ad **: Which of course would need another hook... and run method in
> apache 3.0.

There is no reason to wait for Apache 3.0 to add a new hook.  The whole
reason for the hook abstraction was to make adding hooks painless for
module authors.

Ryan

Re: The word on: adding modules

[Harrie Hazewinkel]

HI,

I am probably not speaking for most of the modules. I have been doing
patching of Apache forever, since otherwise certain 
information/functionality
from Apache cannot be done in an SNMP managed way by MOD-SNMP.



Harrie
--On Wednesday, July 10, 2002 12:26 PM +0200 [EMAIL PROTECTED] wrote:

>
> Right now, as devlopers, we have a whole range of methods of adding in a
> module; from hacking it in, copying it into an existing modules/*
> directory (e.g.  auth, mappers), APXS all the way, down to its own
> directory with a little config.m4.
>
> When documenting 'How to add your modules to apache 2.0' what should be
> official word - i.e. what do we want the instructions on a random
> modules.apache.org or sourceforge module to say:
>
>   1.  APXS prefered
>
>   apxs -c mod_foo.c bar.c comms.c
>

I would think that the most prefered method could be APXS.
WHy do I think this??

1)
For most users it is simple to do:
./configure --enable-module=so ; make ; make install
Followed by building a module with APXS.


2)
On some systems their is now an Apache already available and thus also
APXS. On those systems an user adding a module can easily use APXS
without any fiddling in Apache code/directories.

> Or, if you need it,
>
>   2.  module/foo directory with Makefile.in/config.m4

This would always require a user to compile a module with compiling
Apache as well. APXS could avoid this, if he can retrieve binaries
somewhere else of Apache (like is provided by some companies)

>
> as to allow more Configure(ation) also for the simple case ? I am looking
> for 'the word' :-) as right now the 1.3 situation is messy: dso, static,
> apxs, hack modules,c - and would like to some more guidance for 2.0.
>
> Opinions ? Fears ?


OK, the above opinion does not mean that I think patching should not
be done to the apache core. From a viewpoint of MOD-SNMP, I still
will do it, unless some parts of the code will be made in such a
way that modules can dynamically change/tune the configuration
without restarting the server.

(This is not ment to start discussing dynamic configuration without
restarting, since I know that manye of you oppose this anyway.
With or without good reasoning from those.)



Harrie

Internet Management Consulting
mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
---
Author of MOD-SNMP, enabling SNMP management to the Apache server.
 

Auth checker - long term goal..

[dirkx]

Right now there are zillions of 1.3 auth modules around which have a
check_auth() stage which essentially does:

for each require line
do
if require valid-user
return OK
if require user
then
foreach uid
do
if r->user == uid
return ok
end
endif
end

due to cut-and-paste module creation; and the fact that some people want
to remove mod_auth.c from the server to not have mod_auth.c its own
authenticate_basic_user() against a file in the server.

I am looking at a cookie cutter approach for 2.0 because in 2.0
everything is better (of course!) and I'd like to simplify things as much
as possible.

So if you look at mod_auth_dbm.c in 2.0 we rely on mod_auth.c to be to be
able to do things like

require user foo

even when we are not using AuthUserFile.

Aside: (And when mod_auth is not LoadModule-d in, but mod_auth_dbm is -
things just got a bit more interesting -as we do not keep a tally
as to if each require line is actually used or parsed sensible by
anyone - so interesting things can sneak past the admin which does
not test his server after a change - **).

So I'd like to remove the (not that technically sound) excuses for people
not to have mod_auth.c in the server anymore. I.e. perception mostly.

Would it be fair to say that

->  We want to make it as easy as possible for those old legacy
mod_auth_* modules to be ported - and as a guideline do not want
them  do their own 'require user' stuff anymore.

We want that done central. In a standard module.

->  If we add to mod_auth.c a 'AuthUserFile 'OFF"' or some other
very 'cheap' VISIBLE disbable then there is no reason left for
mod_auth modules to do their own 'require user/require valid user'
work. This would be just to reasure people; the default is NULL
anyway (*). Or alternatively an Auth directive picked up by
mod_auth which uses the ap_auth_type or the source of the info.

Or better perhaps

->  Or alternatively mod_auth is split into a mod_auth and a
a mod_require. The first does the File based username
checking; the latter does the "require valid-user", "require
user foo" checks. 'require group' can stay in mod_auth or
go into a mod_auth_group.

With that out of the way; In the long term may want to do the same for
groups checking which now fundamentally must happen in each module as
group findings are not shared.

I.e. just like we have a r->user have a r->groups field (a table rather
than a char*) which lists the groups the user is part off. (Though I
recognize that there will always be group auth modules which need to to
the reverse; i.e. check if a user is in a list of groups - or, for these
cases, an additional check_group_access handler mirroring the user_access
stage).

Any thoughds ? Note that part of the above problem is perception causing
the duplication of mod_auth because of the file association.

Dw
-- 
Dirk-Willem van Gulik

Ad *: We'd need to touch up the error messages of mod_auth a little.
Ad **: Which of course would need another hook... and run method in
apache 3.0.

RE: Port 80 vs 8080 when not SU.

[Sander Striker]

> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: 10 July 2002 17:20

>> From: Lars Eilebrecht [mailto:[EMAIL PROTECTED]]
>> 
>> According to Ravindra Jaju:
>> 
>>> How about an extra echo:
>>>
>>> if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
>>> conf_port="8080"
>>> echo "Non-root process. Server will run on port $conf_port"
>>> fi
>> 
>> +1
> 
> The problem with this, is that it gets lost in the noise of autoconf.
> Whenever we try to put informative messages like this in the configure
> output, nobody seems it.

Also, I don't want us to outsmart users.  If you want to run on port
80, configure port 80, if you want to run on 8080, configure 8080.
Nothing wrong with that little effort.

-1 on going back to behaviour that in the end will confuse users
(and us) more than it helps.

Sander

Re: Port 80 vs 8080 when not SU.

[Jim Jagielski]

Thom May wrote:
> 
> > How about an extra echo:
> > 
> > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > conf_port="8080"
> > echo "Non-root process. Server will run on port $conf_port"
> > fi
> 
> I think the best solution is to educate the user, rather than to do
> something unexpected.
> if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> echo "You are not currently the superuser. Therefore we can't start
> apache listening on a privileged port (One above 1024)"
> fi
> 

Add to that the "Server will run..." message and the setting to port 8080
and +1 :)

I'd prefer education but also that they get a configuration that they
can test "right after" a build/install :)

-- 
===
   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: MacOS X 10.1.2 libtool

[Pier Fumagalli]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> 
> Any one seen this error, on a pristine MacOS X 10.1.2 machine with a
> freshly cut 2.0.39:
> 
> cd httpd-2.0.39
> ./configure --prefix=/foo
> make && make install
> cd ../test
> apxs -c mod_foo.c
> 
> and then just before then end one gets:
> 
> /foo/runtime/build/libtool --silent --mode=link cc -o
> mod_auth_pam.la -rpath /Users/dirkx/ORA/runtime/modules -module
> -avoid-version -I/usr/local/include  -L/usr/local/lib  mod_auth_pam.lo
> -lpam
> /foo/runtime/build/libtool: parse error: condition expected: xyes = [3183]
> /foo/runtime/mod_auth_pam-1.1/apache-2.0/.libs
> SH_LIBTOOL='/foo/runtime/build/libtool' mod_auth_pam.la
> ...
> 
> But.. this does result in a functional module.
> 
> To add to the insult: running apxs or buildtool with 'sh -x script' in an
> attempt to trace this error makes the error vanish in thin air.

Libtool shipped with MAC doesn't actually produce a MH_BUNDLE dylib... Use
mine http://www.apache.org/~pier/macosx/

Pier

Re: Port 80 vs 8080 when not SU.

[Jacek Prucia]

On Wed, 10 Jul 2002 08:29:06 -0700 (PDT)
Joshua Slive <[EMAIL PROTECTED]> wrote:

> On Wed, 10 Jul 2002, Lars Eilebrecht wrote:
> 
> > According to Ravindra Jaju:
> >
> > > How about an extra echo:
> > >
> > > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > >   conf_port="8080"
> > >   echo "Non-root process. Server will run on port $conf_port"
> > > fi
> >
> > +1
> >
> 
> I don't see how that helps.

As Dirk pointed out, that trick was *default* with Apache 1.3.x. I
personally (and I bet a lot of people out there) simply got used to this
behaviour, and it's a little bit confusing, that new build system acts
differently. That "newbie vs. guru" problem IMO schould not be
considered a valid reason to review this change. I'm with Dirk here
(that is: his oryginal patch, without that echo above).

Since we are talking about build system, let me bring something else up.
Old APACI configure at the end of 'make install' was echoing an ASCII
table with some information (install ok, conf file here, apachectl
there, etc.). This also vanished from 2.0.x build system, but remains in
binary releases. Even if I don't need that personally -- this is another
thing that it is a little bit confusing. After all, adding a no-deps
target that echoes some ASCII stuff can't be thaht hard with
autoconf/automake?

my $cents = 2;

regards,
-- 
Jacek Prucia
7bulls.com S.A.

Re: Port 80 vs 8080 when not SU.

[Thom May]

* Ravindra Jaju ([EMAIL PROTECTED]) wrote :
> On Wed, Jul 10, 2002 at 07:49:25AM -0700, Joshua Slive wrote:
> > On Wed, 10 Jul 2002 [EMAIL PROTECTED] wrote:
> > > In apache 1.3 we had this little trick:
> > >
> > > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > > conf_port="8080"
> > > fi
> > >
> > > to make the port 8080 when the user is not root - thus to reduce the
> > > number of 'apache wont start' newby errors and be generally convenient for
> > > the masses (and disorganized people like me).
> > >
> > > Has that been dropped from 2.0 for a reason or by accident ?
> > 
> > In my opinion, that was never a good idea.  The newbie users are simply
> > confused by this, because they have a server which starts up but can't be
> > accessed at http://localhost/.  And people who do very sensible things
> > like build/install as non-root and then startup as root must go through an
> > extra step to fix this change.
> 
> How about an extra echo:
> 
> if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
>   conf_port="8080"
>   echo "Non-root process. Server will run on port $conf_port"
> fi

I think the best solution is to educate the user, rather than to do
something unexpected.
if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
echo "You are not currently the superuser. Therefore we can't start
apache listening on a privileged port (One above 1024)"
fi

(Line wrapped by mail client, obv this snippet would break)

This also (I guess) presupposes that the admin is trying to start a server
on a priv port. If they're not, then they're gonna be even more pissed if we
change unpriv ports at random on them.
Cheers,
-Thom

-- 
Thom May -> [EMAIL PROTECTED]

Step forward MP3.com founder Michael Robertson, a man with a talent for
soundbites: "All I know is that I'm being sued for unfair business 
practices by Microsoft. Hello pot? It's kettle on line two," he told Reuters.

Re: Port 80 vs 8080 when not SU.

[Joshua Slive]

On Wed, 10 Jul 2002, Lars Eilebrecht wrote:

> According to Ravindra Jaju:
>
> > How about an extra echo:
> >
> > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > conf_port="8080"
> > echo "Non-root process. Server will run on port $conf_port"
> > fi
>
> +1
>

I don't see how that helps.  Newbie users are either going to miss this
entirely as it scrolls by, or are not going to understand the
implications.  (I know a fair bit about apache configuration, and I
wouldn't really be able to parse that if it flew by with no context.)

I'm not sure what the whole hack is trying to solve.  As I said, it seems
to make things more difficult both for newbies and for experienced users.

Joshua.

RE: Port 80 vs 8080 when not SU.

[Ryan Bloom]

> From: Lars Eilebrecht [mailto:[EMAIL PROTECTED]]
> 
> According to Ravindra Jaju:
> 
> > How about an extra echo:
> >
> > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > conf_port="8080"
> > echo "Non-root process. Server will run on port $conf_port"
> > fi
> 
> +1

The problem with this, is that it gets lost in the noise of autoconf.
Whenever we try to put informative messages like this in the configure
output, nobody seems it.

Ryan

Re: Port 80 vs 8080 when not SU.

[Lars Eilebrecht]

According to Ravindra Jaju:

> How about an extra echo:
> 
> if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
>   conf_port="8080"
>   echo "Non-root process. Server will run on port $conf_port"
> fi

+1

ciao...
-- 
Lars Eilebrecht
[EMAIL PROTECTED]

Re: [PATCH] increase file descriptor limit automatically at httpdstartup

[Jeff Trawick]

"Sander Striker" <[EMAIL PROTECTED]> writes:

> > From: Brian Pane [mailto:[EMAIL PROTECTED]]
> > Sent: 10 July 2002 17:00
> 
> > On Wed, 2002-07-10 at 04:16, Jeff Trawick wrote:
> >> Brian Pane <[EMAIL PROTECTED]> writes:
> 
> [...]
> > What do you think about about setting the ulimit in apachectl
> > (and not in the httpd) by default?
> > 
> > That would provide the intended benefit for normal users, but
> > developers doing testing of the out-of-files error handling could
> > easily comment out that line in apachectl.
> 
> I thought we were moving away from apachectl.

We still have to have some shell script to set required environment
variables and which can be used to access arbitrary httpd function.

We still need apachectl since we need to supply something with the
proper user interface for an init script (see Mark Slemko's
back-to-reality post during prior discussions).

Apparently, most folks (not me) want apachectl to fulfill both
requirements.

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

Re: [PATCH] increase file descriptor limit automatically at httpd startup

[Jeff Trawick]

Brian Pane <[EMAIL PROTECTED]> writes:

> > 2) shouldn't the user be able to control how many file descriptors
> >can be used by Apache?  in general, they should be able to mitigate
> >the resource growth caused by an Apache or module bug by playing
> >with soft limits
> > 
> >a) this makes it harder to simulate running out of file descriptors
> >   during testing
> > 
> >   without the patch, "ulimit -n 20" will generate some excitement;
> >   with the patch, it is off to the OS documentation to figure out
> >   how to change the hard limit on various systems
> 
> What do you think about about setting the ulimit in apachectl
> (and not in the httpd) by default?

I think that is a good idea.

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

RE: [PATCH] increase file descriptor limit automatically at httpdstartup

[Sander Striker]

> From: Brian Pane [mailto:[EMAIL PROTECTED]]
> Sent: 10 July 2002 17:00

> On Wed, 2002-07-10 at 04:16, Jeff Trawick wrote:
>> Brian Pane <[EMAIL PROTECTED]> writes:

[...]
> What do you think about about setting the ulimit in apachectl
> (and not in the httpd) by default?
> 
> That would provide the intended benefit for normal users, but
> developers doing testing of the out-of-files error handling could
> easily comment out that line in apachectl.

I thought we were moving away from apachectl.

Sander

Re: [PATCH] increase file descriptor limit automatically at httpdstartup

[Brian Pane]

On Wed, 2002-07-10 at 04:16, Jeff Trawick wrote:
> Brian Pane <[EMAIL PROTECTED]> writes:
> 
> > This patch increases the maximum number of open files
> > at httpd startup.  Before I commit, does anyone have a
> > scenario in which it won't be safe to do this?
> 
> devil's advocate comments:
> 
> 1) why write code to do something the user can easily take care of?

Mostly to avoid the converse devil's avocate question:
"Why make every user of the worker MPM write a wrapper script
to do something that the httpd can easily take care of?" :-)

> 2) shouldn't the user be able to control how many file descriptors
>can be used by Apache?  in general, they should be able to mitigate
>the resource growth caused by an Apache or module bug by playing
>with soft limits
> 
>a) this makes it harder to simulate running out of file descriptors
>   during testing
> 
>   without the patch, "ulimit -n 20" will generate some excitement;
>   with the patch, it is off to the OS documentation to figure out
>   how to change the hard limit on various systems

What do you think about about setting the ulimit in apachectl
(and not in the httpd) by default?

That would provide the intended benefit for normal users, but
developers doing testing of the out-of-files error handling could
easily comment out that line in apachectl.

--Brian

Re: Port 80 vs 8080 when not SU.

[Ravindra Jaju]

On Wed, Jul 10, 2002 at 07:49:25AM -0700, Joshua Slive wrote:
> On Wed, 10 Jul 2002 [EMAIL PROTECTED] wrote:
> > In apache 1.3 we had this little trick:
> >
> > if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> > conf_port="8080"
> > fi
> >
> > to make the port 8080 when the user is not root - thus to reduce the
> > number of 'apache wont start' newby errors and be generally convenient for
> > the masses (and disorganized people like me).
> >
> > Has that been dropped from 2.0 for a reason or by accident ?
> 
> In my opinion, that was never a good idea.  The newbie users are simply
> confused by this, because they have a server which starts up but can't be
> accessed at http://localhost/.  And people who do very sensible things
> like build/install as non-root and then startup as root must go through an
> extra step to fix this change.

How about an extra echo:

if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
conf_port="8080"
echo "Non-root process. Server will run on port $conf_port"
fi

?

regards,
jaju

Preventing access to certain files via the server process

[Ravindra Jaju]

Hi.

Consider the following scenario.

In directory PRODIR ( short for protected directory ), I have certain
files which contain sensitive information ( say, database passwords,
embedded in some PHP scripts ). Let's consider "passwords.inc"

The PRODIR is protected with the .htaccess file, so no one can
_directly_ access those files through the web-server.

Files:
$PRODIR/.ht*
$PRODIR/passwords.inc

I don't want the passwords to be seen by other users on the same
system as well. So, the file permissions are such that others can't
see those files ( owner=user, group=group-of-apache-process and
perms = 750 )

Now -

bash$ cat $UNPRODIR/crack.php


Obviously, PHP ( or anything else ) won't respect the rules set for Apache.
Is there a way in which such add-ons ( like PHP ) can call Apache back
for such authorization services?

Of course, there can be work-arounds like making the user supply extra
information ( login/password ) through the browser and then using cookies,
but is there any other way?

regards,
jaju

Re: Port 80 vs 8080 when not SU.

[Joshua Slive]

On Wed, 10 Jul 2002 [EMAIL PROTECTED] wrote:
> In apache 1.3 we had this little trick:
>
> if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
> conf_port="8080"
> fi
>
> to make the port 8080 when the user is not root - thus to reduce the
> number of 'apache wont start' newby errors and be generally convenient for
> the masses (and disorganized people like me).
>
> Has that been dropped from 2.0 for a reason or by accident ?

In my opinion, that was never a good idea.  The newbie users are simply
confused by this, because they have a server which starts up but can't be
accessed at http://localhost/.  And people who do very sensible things
like build/install as non-root and then startup as root must go through an
extra step to fix this change.

Joshua.

MacOS X 10.1.2 libtool

[dirkx]

Any one seen this error, on a pristine MacOS X 10.1.2 machine with a
freshly cut 2.0.39:

cd httpd-2.0.39
./configure --prefix=/foo
make && make install
cd ../test
apxs -c mod_foo.c

and then just before then end one gets:

/foo/runtime/build/libtool --silent --mode=link cc -o
mod_auth_pam.la -rpath /Users/dirkx/ORA/runtime/modules -module
-avoid-version -I/usr/local/include  -L/usr/local/lib  mod_auth_pam.lo
-lpam
/foo/runtime/build/libtool: parse error: condition expected: xyes = [3183]
/foo/runtime/mod_auth_pam-1.1/apache-2.0/.libs
SH_LIBTOOL='/foo/runtime/build/libtool' mod_auth_pam.la
...

But.. this does result in a functional module.

To add to the insult: running apxs or buildtool with 'sh -x script' in an
attempt to trace this error makes the error vanish in thin air.

Dw

Port 80 vs 8080 when not SU.

[dirkx]

In apache 1.3 we had this little trick:

if [ "x`$aux/getuid.sh`" != "x0" -a "x$port" = "x" ]; then
conf_port="8080"
fi

to make the port 8080 when the user is not root - thus to reduce the
number of 'apache wont start' newby errors and be generally convenient for
the masses (and disorganized people like me).

Has that been dropped from 2.0 for a reason or by accident ?

Dw.

-- 
Dirk-Willem van Gulik

when to whack exports.c (to handle weird cases)

[Jeff Trawick]

A little bird told me that exports.c is not automatically regenerated
if you remove a header file.  You have to manually remove exports.c or
run "make extraclean."

The normal user would probably think that "make clean" would clean up
any such issues.  Does anybody care?  If so, it should be sufficient
to edit server/Makefile.in and change it to something like this:

  CLEAN_TARGETS =  exports.c export_vars.h
  ...
  EXTRACLEAN_TARGETS =

It seems reasonable to me that "make clean" should take care of this.
Any counteropinions?

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

proxy debug messages and passwords :)

[Jeff Trawick]

I overlaid the actual logged password with  in the messages
below.

Maybe proxy should contruct a printable URL for use in debug messages,
where the optional password has been replaced with ? or some other
character?

[Wed Jul 10 09:14:31 2002] [debug] proxy_ftp.c(193): proxy: FTP: canonicalising URL 
//trawick:@192.168.1.1/
[Wed Jul 10 09:14:31 2002] [debug] mod_proxy.c(461): Trying to run scheme_handler
[Wed Jul 10 09:14:31 2002] [debug] proxy_http.c(1036): proxy: HTTP: declining URL 
ftp://trawick:@192.168.1.1/
[Wed Jul 10 09:14:31 2002] [debug] proxy_connect.c(144): proxy: CONNECT: declining URL 
ftp://trawick:@192.168.1.1/
[Wed Jul 10 09:14:31 2002] [debug] proxy_ftp.c(823): proxy: FTP: serving URL 
ftp://trawick:@192.168.1.1/
[Wed Jul 10 09:14:31 2002] [debug] proxy_ftp.c(916): proxy: FTP: connecting 
ftp://trawick:@192.168.1.1/ to 192.168.1.1:21
[Wed Jul 10 09:14:31 2002] [debug] proxy_util.c(988): proxy: checking remote machine 
[192.168.1.1] against [192.168.1.1]
[Wed Jul 10 09:14:31 2002] [warn] proxy: connect to remote machine 192.168.1.1 
blocked: name 192.168.1.1 matched
[Wed Jul 10 09:14:31 2002] [error] [client 192.168.1.1] proxy: Connect to remote 
machine blocked returned by ftp://trawick:@192.168.1.1/

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

Re: time for a 2.0.40 me thinks

[Brian Pane]

Bill Stoddard wrote:

>>William A. Rowe, Jr. wrote:
>>
>>
>>
>>>At 12:18 PM 7/9/2002, Bill Stoddard wrote:
>>>
>>>  
>>>
>I'm going to do a start the T&R process on thursday for a 2.0.40
>  
>
release


>so if you've got things which you want in there and are stable
>(apr_poll) comes to mind please commit them.
>
>Ian
>  
>
I'll try to run a profile on the new apr_poll code posted by Ryan this
afternoon or evening.  It would be -really- good if we could make the
apr_time changes before 2.0.40...


>>>Agreed.  They are in or out.  BPane... any new news on profiling with
>>>busec values?
>>>  
>>>
>>No news; I don't expect that I'll be able to work on this
>>for a while.
>>
>>--Brian
>>
>>
>
>Where and when was the post that described this proposal?  I'd like to take
>a look. Is there a patch?
>

There's no patch that I know of, but here's the thread with wrowe's
original proposal for the binary microseconds design:
  http://marc.theaimsgroup.com/?l=apr-dev&m=102376298728487&w=2

With the big batch of changes that I made last week, almost all
of the time-related code in the httpd now uses the new macros--
apr_time_sec(), apr_time_usec(), etc--instead of multiplying and
dividing by 1,000,000 directly.  Hopefully that will make it
easier to try out a new time representation.

--Brian

[PATCH] define proxy-specific hook macros

[Jeff Trawick]

This defines macros similar to the AP_ counterparts in ap_config.h.  I
was playing with a new proxy hook and optionally implementing the hook
in a non-proxy module when I encountered the need to use APR_ hook
macros to make it work.

It would seem to be consistent and friendly to define these new PROXY_
hook macros, but it is not absolutely required.

Opinions?

Index: modules/proxy/mod_proxy.h
===
RCS file: /cvs/phoenix/2.0.39/modules/proxy/mod_proxy.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mod_proxy.h
--- modules/proxy/mod_proxy.h   20 Jun 2002 13:12:20 -  1.1.1.1
+++ modules/proxy/mod_proxy.h   10 Jul 2002 12:13:42 -
@@ -241,6 +241,21 @@
 #define PROXY_DECLARE_DATA __declspec(dllimport)
 #endif
 
+/**
+ * Hook an optional proxy hook.  Unlike static hooks, this uses a macro
+ * instead of a function.
+ */
+#define PROXY_OPTIONAL_HOOK(name,fn,pre,succ,order) \
+APR_OPTIONAL_HOOK(proxy,name,fn,pre,succ,order)
+/**
+ * Declare a proxy hook function
+ * @param ret The return type of the hook
+ * @param name The hook's name (as a literal)
+ * @param args The arguments the hook function takes, in brackets.
+ */
+#define PROXY_DECLARE_HOOK(ret,name,args) \
+   APR_DECLARE_EXTERNAL_HOOK(proxy,PROXY,ret,name,args)
+
 APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, scheme_handler, (request_rec *r, 
   proxy_server_conf *conf, char *url, 
   const char *proxyhost, apr_port_t proxyport))
@@ -249,6 +264,9 @@
 
 APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, create_req, (request_rec *r, request_rec 
*pr))
 APR_DECLARE_EXTERNAL_HOOK(proxy, PROXY, int, fixups, (request_rec *r)) 
 
 /* proxy_util.c */
 

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

[PATCH] Patch to compile apache-1.3.20+ on LynxOS-3.0.1

[Fulvio Bille`]

Hi,
this patch enable to run configure and compile on LynxOS-3.0.1
Any source file is modified.
Only Configure, GuessOS, mkshadow.sh and ap_config.h are modified.
Bye.

Fulvio Bille`

===
diff -ruN ./src/Configure ../apache_1.3.26-patched/src/Configure
--- ./src/Configure Tue Jun 18 07:20:33 2002
+++ ../apache_1.3.26-patched/src/Configure Fri Jul  5 14:11:18 2002
@@ -472,6 +472,13 @@
  LIBS="$LIBS -lbsd -lcrypt"
  DEF_WANTHSREGEX=yes
  ;;
+*-lynx-lynxos3)
+ OS='LynxOS 3.x'
+ CFLAGS="$CFLAGS -D__NO_INCLUDE_WARN__ -DLYNXOS3"
+ LIBS="$LIBS -lbsd -lcrypt"
+ DEF_WANTHSREGEX=yes
+ INCLUDES=-I/usr/include
+ ;;
 *486-*-bsdi*)
  OS='BSDI w/486'
  CFLAGS="$CFLAGS -m486"
diff -ruN ./src/helpers/GuessOS
../apache_1.3.26-patched/src/helpers/GuessOS
--- ./src/helpers/GuessOS Mon Oct  8 17:49:33 2001
+++ ../apache_1.3.26-patched/src/helpers/GuessOS Fri Jul  5 14:11:18
2002
@@ -134,6 +134,10 @@
  echo "${MACHINE}-GNU-GNU/Hurd"; exit 0
  ;;

+LynxOS:3*:*)
+ echo "${MACHINE}-lynx-lynxos3"; exit 0
+ ;;
+
 LynxOS:*)
  echo "${MACHINE}-lynx-lynxos"; exit 0
  ;;
diff -ruN ./src/helpers/mkshadow.sh
../apache_1.3.26-patched/src/helpers/mkshadow.sh
--- ./src/helpers/mkshadow.sh Tue Jun 29 15:43:15 1999
+++ ../apache_1.3.26-patched/src/helpers/mkshadow.sh Fri Jul  5 14:11:19

2002
@@ -65,7 +65,7 @@

 #   fill directory tree with symlinks to files
 FILES="`cd $src; \
-find . -depth -print |\
+find . -print |\
 sed -e '/\.o$/d' \
 -e '/\.a$/d' \
 -e '/\.so$/d' \
diff -ruN ./src/include/ap_config.h
../apache_1.3.26-patched/src/include/ap_config.h
--- ./src/include/ap_config.h Mon Jun  3 14:28:27 2002
+++ ../apache_1.3.26-patched/src/include/ap_config.h Wed Jul 10 11:03:59

2002
@@ -787,6 +787,22 @@
 typedef int rlim_t;
 #define HAVE_SYSLOG 1

+#elif defined(LYNXOS3)
+#undef HAVE_GMTOFF
+#undef USE_MMAP_SCOREBOARD
+#undef USE_SHMGET_SCOREBOARD
+#undef USE_POSIX_SCOREBOARD
+#define HAVE_FCNTL_SERIALIZED_ACCEPT
+#define USE_FCNTL_SERIALIZED_ACCEPT
+#define USE_LONGJMP
+#undef NO_KILLPG
+#undef NO_SETSID
+#undef NO_USE_SIGACTION
+#undef NO_LINGCLOSE
+extern char *crypt(char *pw, char *salt);
+typedef long rlim_t;
+#define HAVE_SYSLOG 1
+
 #elif defined(UXPDS)
 #undef NEED_STRCASECMP
 #undef NEED_STRNCASECMP

===



Dr. Eng. Fulvio Bille`

Software Group
Experimental Division
Sincrotrone Trieste S.C.p.A.
Elettra Synchrotron Light Laboratory
S.S. 14 Km 163.5, in Area Science Park
34012 Basovizza - Trieste (Italy)

e-mail: [EMAIL PROTECTED]
URL:http://www.elettra.trieste.it/

[PATCH] XHTML1.1 Error-Docs

[Erik Abele]

Hi!

Some weeks ago I posted the attached patch on the docs-list. Last week I
posted it a second time, but didn't receive any replies. Therefore I am
posting it here on the dev-list...

The patch modifies the present error doc templates (spacer.html, top.html,
bottom.html) to be valid XHTML 1.1 documents.

To ensure their correctness, I validated all the resulting error documents
(the ssi-parsed output) at w3.org.

I also had to correct the -tags in HTTP_INTERNAL_SERVER_ERROR.html.var
and an -tag in contact.html.var (see patch).

cheers,
erik


> Von: Justin Erenkrantz <[EMAIL PROTECTED]>
> An: [EMAIL PROTECTED]
> Betreff: Re: Valid XHTML Error-Docs
> 
> On Wed, Jun 19, 2002 at 09:05:00PM +0200, Erik Abele wrote:
>> I would also prefer valid XHTML-Documents, but I don't want to convert all
>> the files if they won't be included.
> 
> +1 especially if someone contributes them!  -- justin



Index: httpd-docs-2.0/error/HTTP_INTERNAL_SERVER_ERROR.html.var
===
RCS file: /home/cvspublic/httpd-2.0/docs/error/HTTP_INTERNAL_SERVER_ERROR.html.var,v
retrieving revision 1.3
diff -u -I*.AppleDouble -r1.3 HTTP_INTERNAL_SERVER_ERROR.html.var
--- httpd-docs-2.0/error/HTTP_INTERNAL_SERVER_ERROR.html.var18 Jun 2002 22:34:34 
-  1.3
+++ httpd-docs-2.0/error/HTTP_INTERNAL_SERVER_ERROR.html.var8 Jul 2002 18:04:48 
+-
@@ -12,7 +12,7 @@
 
 
 Fehlermeldung:
-
+
 
 
   
@@ -38,7 +38,7 @@
 
 
 Error message:
-
+
 
   
 
@@ -65,7 +65,7 @@
 
 
 Mensaje de error:
-
+
 
   
 
@@ -94,7 +94,7 @@
 
 
 Message d'erreur:
-
+
 
   
 
Index: httpd-docs-2.0/error/contact.html.var
===
RCS file: /home/cvspublic/httpd-2.0/docs/error/contact.html.var,v
retrieving revision 1.5
diff -u -I*.AppleDouble -r1.5 contact.html.var
--- httpd-docs-2.0/error/contact.html.var   18 Jun 2002 22:34:34 -  1.5
+++ httpd-docs-2.0/error/contact.html.var   8 Jul 2002 18:04:48 -
@@ -1,24 +1,24 @@
 Content-language: de
 Content-type: text/html
 Body:--de--
- Sofern Sie dies für eine Fehlfunktion des Servers halten,
- informieren Sie bitte den
- ">Webmaster
- hierüber.
+Sofern Sie dies für eine Fehlfunktion des Servers halten,
+informieren Sie bitte den
+">Webmaster
+hierüber.
 --de--
 
 Content-language: en
 Content-type: text/html
 Body:--en--
- If you think this is a server error, please contact
- the ">webmaster
+If you think this is a server error, please contact
+the ">webmaster
 --en--
 
 Content-language: es
 Content-type: text/html
 Body:--es--
 Favor de contactar al 
-">webmaster
+">webmaster
 en caso de que usted crea que existe un error en el servidor. 
 --es--
 
@@ -26,5 +26,5 @@
 Content-type: text/html
 Body:--fr--
 Si vous pensez qu'il s'agit d'une erreur du serveur, veuillez contacter 
-le ">gestionnaire du 
site   
+le ">gestionnaire du 
+site   
 --fr--
Index: httpd-docs-2.0/error/include/bottom.html
===
RCS file: /home/cvspublic/httpd-2.0/docs/error/include/bottom.html,v
retrieving revision 1.10
diff -u -I*.AppleDouble -r1.10 bottom.html
--- httpd-docs-2.0/error/include/bottom.html20 Jun 2002 03:51:46 -  1.10
+++ httpd-docs-2.0/error/include/bottom.html8 Jul 2002 18:04:49 -
@@ -1,19 +1,19 @@
-
+
 
-
+
 
-Error 
-
-
-
-  
-  
+Error 
+
+
+
+  
+  
   
   
-  
-
+  
   
-
-
-
-
+
+
+
+
+
Index: httpd-docs-2.0/error/include/spacer.html
===
RCS file: /home/cvspublic/httpd-2.0/docs/error/include/spacer.html,v
retrieving revision 1.1
diff -u -I*.AppleDouble -r1.1 spacer.html
--- httpd-docs-2.0/error/include/spacer.html19 Aug 2001 01:01:51 -  1.1
+++ httpd-docs-2.0/error/include/spacer.html8 Jul 2002 18:04:49 -
@@ -1 +1 @@
-
+
Index: httpd-docs-2.0/error/include/top.html
===
RCS file: /home/cvspublic/httpd-2.0/docs/error/include/top.html,v
retrieving revision 1.4
diff -u -I*.AppleDouble -r1.4 top.html
--- httpd-docs-2.0/error/include/top.html   21 Aug 2001 01:31:23 -  1.4
+++ httpd-docs-2.0/error/include/top.html   8 Jul 2002 18:04:49 -
@@ -1,11 +1,20 @@
-
-
-
-
-">
-
+
+http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";>
+http://www.w3.org/1999/xhtml"; xml:lang="en">
+
+
+
+" />
+
+
+
+
 
-
-
-
-
+
+
+
+

Re: umask and modules/dav/fs

[Jeff Trawick]

Scott Lamb <[EMAIL PROTECTED]> writes:

> I'd like to allow people to update a website either through their
> shell account or WebDAV. My problem is permissions. I can make a group
> "somewebsite" including users apache, bob, and charlie. Then I can
> make all the directories setgid. When bob and charlie make new files
> or directories, everything works out. When Apache does, there's a
> problem: the group write permission is disabled. bob and charlie can't
> modify the file.
> 
> I grepped through the source for umask and found this:
> 
>  ./modules/dav/fs/dbm.c:/* ### do we need to deal with the umask? */
>  ./modules/dav/fs/dbm.c:/* ### do we need to deal with the umask? */
>  ./modules/dav/fs/repos.c:/* ### do we need to deal with the
> umask? */
>  ./modules/dav/fs/repos.c:/* ### do we need to deal with the
> umask? */
> 
> I think the answer is yes. In my situation, just setting the umask
> globally would work. Are there situations where it'd need to be set on
> a per-directory basis? I.e., is there need for a "DavUmask" directive
> that can be set in  containers?

Perhaps I'm confused, but here goes:

umask only serves to turn off permission bits in the permissions
specified by the program...

mod_dav always specifies 0666 when creating files on Unix, which would
seem to give the admin a lot of leeway in playing with umask (set
umask to desired value in shell before starting Apache); that would
seem to satisfy your desire for a global umask setting...

is the g+s bit getting lost in directories created by Apache/Dav?

have you played with umask in the shell before starting Apache?

I'm unsure about whether a lost g+s bit or a bad umask is causing the
problem.

(I'm even unsure that I know what I'm talking about, but maybe this
will bring out some fresh ideas.)

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

Re: [PATCH] increase file descriptor limit automatically at httpd startup

[Jeff Trawick]

Brian Pane <[EMAIL PROTECTED]> writes:

> This patch increases the maximum number of open files
> at httpd startup.  Before I commit, does anyone have a
> scenario in which it won't be safe to do this?

devil's advocate comments:

1) why write code to do something the user can easily take care of?

2) shouldn't the user be able to control how many file descriptors
   can be used by Apache?  in general, they should be able to mitigate
   the resource growth caused by an Apache or module bug by playing
   with soft limits

   a) this makes it harder to simulate running out of file descriptors
  during testing

  without the patch, "ulimit -n 20" will generate some excitement;
  with the patch, it is off to the OS documentation to figure out
  how to change the hard limit on various systems

(OTOH, I too would speculate that this would make life easier for some
Apache users :) )

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

The word on: adding modules

[dirkx]

Right now, as devlopers, we have a whole range of methods of adding in a
module; from hacking it in, copying it into an existing modules/*
directory (e.g.  auth, mappers), APXS all the way, down to its own
directory with a little config.m4.

When documenting 'How to add your modules to apache 2.0' what should be
official word - i.e. what do we want the instructions on a random
modules.apache.org or sourceforge module to say:

1.  APXS prefered

apxs -c mod_foo.c bar.c comms.c

Or, if you need it,

2.  module/foo directory with Makefile.in/config.m4

as to allow more Configure(ation) also for the simple case ? I am looking
for 'the word' :-) as right now the 1.3 situation is messy: dso, static,
apxs, hack modules,c - and would like to some more guidance for 2.0.

Opinions ? Fears ?

Dw
-- 
Dirk-Willem van Gulik