HTML5 and WebSocket
I don't know if anyone is httpd land is following the HTML5 proposals, specifically the newer stuff being called WebSockets: http://www.whatwg.org/specs/web-apps/current-work/#network And a blog post about it: http://www.jroller.com/tedgoddard/entry/websocket_is_neither_web_nor Mostly I am wondering if anyone from the httpd world is tracking where this is going, and has time to make sure they don't do anything crazy, since they seem to be heading down the path of trying to use HTTP 1.1 Upgrade header stuff to implement bi-directional communication between the UA and Server. Thanks, -Paul
Re: HTML5 and WebSocket
- Paul Querna: I don't know if anyone is httpd land is following the HTML5 proposals, specifically the newer stuff being called WebSockets: http://www.whatwg.org/specs/web-apps/current-work/#network And a blog post about it: http://www.jroller.com/tedgoddard/entry/websocket_is_neither_web_nor Mostly I am wondering if anyone from the httpd world is tracking where this is going, and has time to make sure they don't do anything crazy, since they seem to be heading down the path of trying to use HTTP 1.1 Upgrade header stuff to implement bi-directional communication between the UA and Server. Thanks, -Paul It's a an excitement, HTML5 will make web application very easy and strong. It's very good
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
On Tue, 28 Oct 2008, Paul Querna wrote:
-1.
IIRC and pretty much all modern are both bad reasons for being sloppy
;-)
IIRC ( :- ) the AIX compiler actually doesn't like it, but other people
know that better.
Then lets not support AIX :-)
To expand on my beliefs around this a little bit, if a platform doesn't have
things like kqueue, epool or event ports, and it still doesn't have a c99
compiler, where is the value in supporting it, they are likely still using
Apache 1.3 anyways.
Feels like we're going from lets be portable to if it's not the
latestgreatest linux-distro that I use lets drop it. Sounds like a
bad decision to me.
For the record, Takashis example compiles with a recent AIX compiler
(VAC 9) when using cc, xlc, and c99.
I'm for avoiding c99 for a while though, there are still a lot of c99
related bugs that show up in different compilers, and I don't really
thing we can gain that much by jumping on the c99 bandwagon.
And lets continue being portable, please.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---
It's better to be rich and healthy than poor and sick
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Broken trunk build
I've just tried a clean trunk build, to play with Paul's simple MPM. Unfortunately buildconf fails around autoheader and autoconf: rebuilding include/ap_config_auto.h.in NONE:0: m4: ERROR: EOF in string autom4te: m4 failed with exit status: 1 autoheader: autom4te failed with exit status: 1 rebuilding configure NONE:0: m4: ERROR: EOF in string autom4te: m4 failed with exit status: 1 A bit of googling suggests the culprit may be unbalanced brackets or quotes somewhere in the M4, but I'm struggling to find out where to look. Any clues for hunting down the cause of this? -- Nick Kew
Re: Broken trunk build
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Auftrag von Nick Kew Gesendet: Mittwoch, 29. Oktober 2008 12:18 An: dev@httpd.apache.org Betreff: Broken trunk build I've just tried a clean trunk build, to play with Paul's simple MPM. Unfortunately buildconf fails around autoheader and autoconf: rebuilding include/ap_config_auto.h.in NONE:0: m4: ERROR: EOF in string autom4te: m4 failed with exit status: 1 autoheader: autom4te failed with exit status: 1 rebuilding configure NONE:0: m4: ERROR: EOF in string autom4te: m4 failed with exit status: 1 A bit of googling suggests the culprit may be unbalanced brackets or quotes somewhere in the M4, but I'm struggling to find out where to look. Any clues for hunting down the cause of this? Hm. I cannot reproduce this. Did you issue a 'make extraclean' before? Regards Rüdiger
Re: Simple MPM is in trunk
On Tue, Oct 28, 2008 at 12:12:51AM -0700, Paul Querna wrote: I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ Great! - The name. Someone suggest something better than Simple. I like naming projects by grepping the dictionary, and grepping for 'm.*p.*m' came up with wampum (amongst 1173 others ;), which is a North American Indian word, apparently - seems fitting. joe
Re: Simple MPM is in trunk
On Wed, Oct 29, 2008 at 7:32 AM, Joe Orton [EMAIL PROTECTED] wrote: On Tue, Oct 28, 2008 at 12:12:51AM -0700, Paul Querna wrote: I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ Great! - The name. Someone suggest something better than Simple. I like naming projects by grepping the dictionary, and grepping for 'm.*p.*m' came up with wampum (amongst 1173 others ;), which is a North American Indian word, apparently - seems fitting. same approach, but anchoring the m to the beginning has two fun but unruly matches: morpheme and malapropism. -- Eric Covener [EMAIL PROTECTED]
Re: Broken trunk build
Nick Kew wrote: Plüm, Rüdiger, VF-Group wrote: [SNIP] ... This m4 is nasty! +1 on that
Introducing modules/system
Inspired by a combination of my own work and Paul´s simple MPM, I´ve created a mod_unixd. Basically it´s unixd.c, turned into a module. In particular, it reintroduces the stuff marked TODO in Paul´s simple_setup_privs, but puts it in a child_init hook. So supporting unixd-equivalent stuff on other platforms with mpm-simple becomes a matter of writing a module, or turning existing code into a module. I´ve added modules/system to local svn. Any objection to my committing that? I intend introducing mod_privileges (a much more interesting alternative to mod_unixd) there in due course, and if we adopt mpm-simple we´ll want comparable system modules for non-unixlike platforms there too. -- Nick Kew
Re: Introducing modules/system
Nick Kew wrote: Inspired by a combination of my own work and Paul´s simple MPM, I´ve created a mod_unixd. Basically it´s unixd.c, turned into a module. In particular, it reintroduces the stuff marked TODO in Paul´s simple_setup_privs, but puts it in a child_init hook. So supporting unixd-equivalent stuff on other platforms with mpm-simple becomes a matter of writing a module, or turning existing code into a module. I´ve added modules/system to local svn. Any objection to my committing that? I intend introducing mod_privileges (a much more interesting alternative to mod_unixd) there in due course, and if we adopt mpm-simple we´ll want comparable system modules for non-unixlike platforms there too. Just do it, its trunk :) -Paul
MPMs, COW vs Child Process Spawning
Is COW ability of fork important enough with modern memory and operating systems, to maintain two significantly different code paths for spawning children processes? Background: One of the things I would like to do on the Simple MPM is unify how child processes are created on win32 and unix. On Win32, there is no fork, so roughly speaking what the current winnt MPM creates a new process, and feeds the configuration over a pipe to the new child. On Unix, all of the current MPMs use fork, and do not execute a new process, but instead then drop privileges and continue running. What I would like to do, is change Unix to use the same pattern as on Windows. Doing this could also solves some issues with on some platforms[2]. It is common on most unix platforms for fork() to use copy on write[1] for memory pages. This means when spawning a child it uses much less 'real' memory, compared to spawning a completely new process. [1] - http://en.wikipedia.org/wiki/Copy-on-write [2] - https://trac.macports.org/ticket/16340
Re: MPMs, COW vs Child Process Spawning
Paul Querna wrote: Doing this could also solves some issues with on some platforms[2]. ... [2] - https://trac.macports.org/ticket/16340 See also: https://issues.apache.org/bugzilla/show_bug.cgi?id=44250 http://bugs.python.org/issue1676
Re: MPMs, COW vs Child Process Spawning
Paul Querna wrote: One of the things I would like to do on the Simple MPM is unify how child processes are created on win32 and unix. On Win32, there is no fork, so roughly speaking what the current winnt MPM creates a new process, and feeds the configuration over a pipe to the new child. On Unix, all of the current MPMs use fork, and do not execute a new process, but instead then drop privileges and continue running. What I would like to do, is change Unix to use the same pattern as on Windows. Hmmm. I think for a large configurations, the copy on write is a significant optimisation - you can have large numbers of processes, and a large configuration, and get away with it, as practically the configuration is only memory resident once. I think it would be important to still support both, but certainly the code to support both shouldn't be at all complex. Perhaps the choice of which to choose could be configurable, so that Leopard users could choose config via pipe. Although the MPM should be simple, it should ideally not be so simplified to become simplistic. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: MPMs, COW vs Child Process Spawning
On Wed, Oct 29, 2008 at 8:28 PM, Graham Leggett [EMAIL PROTECTED] wrote: Paul Querna wrote: One of the things I would like to do on the Simple MPM is unify how child processes are created on win32 and unix. On Win32, there is no fork, so roughly speaking what the current winnt MPM creates a new process, and feeds the configuration over a pipe to the new child. On Unix, all of the current MPMs use fork, and do not execute a new process, but instead then drop privileges and continue running. What I would like to do, is change Unix to use the same pattern as on Windows. Hmmm. I think for a large configurations, the copy on write is a significant optimisation - you can have large numbers of processes, and a large configuration, and get away with it, as practically the configuration is only memory resident once. I think it would be important to still support both, but certainly the code to support both shouldn't be at all complex. Perhaps the choice of which to choose could be configurable, so that Leopard users could choose config via pipe. If you are going to implement both methodes... fork() should be used and exec and pipe the config as a fallback. Then I know nothing about mpm's so I'll keep quite now. Although the MPM should be simple, it should ideally not be so simplified to become simplistic. Regards, Graham -- ~ Jorge
Re: MPMs, COW vs Child Process Spawning
Jorge Schrauwen wrote: I think for a large configurations, the copy on write is a significant optimisation - you can have large numbers of processes, and a large configuration, and get away with it, as practically the configuration is only memory resident once. I think it would be important to still support both, but certainly the code to support both shouldn't be at all complex. Perhaps the choice of which to choose could be configurable, so that Leopard users could choose config via pipe. If you are going to implement both methodes... fork() should be used and exec and pipe the config as a fallback. Well, part of the problem is that many current apache modules assume that the parent and child are fork'ed from one another -- this is a wrong assumption of course, since,it doesn't work on win32 that way -- but most of those modules are win32 only of course. If we do this on unix, we will break all of those modules. Of course, maybe that is a good thing, since then they would be ported forward and work on win32 too. -Paul
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Niklas Edmundsson wrote: Feels like we're going from lets be portable to if it's not the latestgreatest linux-distro that I use lets drop it. Sounds like a bad decision to me. ... And lets continue being portable, please. FWIW, I don't believe in latest and greatest linux distro as a good measure, but I do believe that there are only a few platforms that we should make design decisions around: - Linux 2.6 - FreeBSD 7 - Solaris 10 - Windows Vista If something is *fast* or *good* and can be done on all of the above platforms, I would argue we should do it from a design perspective, and I'm very much opposed to limiting how we design stuff based on the constraints of other less popular operating systems, cf epoll/kqueue/event ports. -Paul
Re: svn commit: r708935 - in /httpd/httpd/trunk: CHANGES modules/system/ modules/system/mod_unixd.c server/mpm/simple/simple_run.c
On 10/29/2008 05:41 PM, [EMAIL PROTECTED] wrote: Author: niq Date: Wed Oct 29 09:41:10 2008 New Revision: 708935 URL: http://svn.apache.org/viewvc?rev=708935view=rev Log: Introduce modules/system, and mod_unixd.c mod_unixd.c is only os/unix/unixd.c, turned into a module. (or more accurately, an ugly hack). Work in progress, and the old unixd will have to go once the module build stuff is in place. This re-introduces some of the unixd stuff (set user, group and chroot) to mpm_simple, and should work equally well with existing MPMs. It also paves the way for alternative privilege management schemes, which can be implemented in alternative modules: this´ll be necessary to run mpm_simple on non-unix-family platforms, and of interest for alternative Unix implementations. By relegating everything to a child_init hook, we can mix-and-match, though weĺl need to add a regime that prevents just going right ahead with nothing and running as root. Round tuits permitting, we should be able to simplify unixd.h too, and look towards eliminating it. Just a remark. In all current MPM's ap_run_child_init runs with the root privileges already dropped. In the simple MPM this is now different in general (we are running with root priviledges here). But as mod_unixd registers an APR_HOOK_FIRST hook this will not make a difference for most modules as their child_init hooks are still run with the privileges already dropped. As said just a remark and no comment as I haven't made up my mind so far if this is good or bad. Regards Rüdiger
Re: svn commit: r708935 - in /httpd/httpd/trunk: CHANGES modules/system/ modules/system/mod_unixd.c server/mpm/simple/simple_run.c
Ruediger Pluem wrote: On 10/29/2008 05:41 PM, [EMAIL PROTECTED] wrote: Author: niq Date: Wed Oct 29 09:41:10 2008 New Revision: 708935 URL: http://svn.apache.org/viewvc?rev=708935view=rev Log: Introduce modules/system, and mod_unixd.c mod_unixd.c is only os/unix/unixd.c, turned into a module. (or more accurately, an ugly hack). Work in progress, and the old unixd will have to go once the module build stuff is in place. Just a remark. In all current MPM's ap_run_child_init runs with the root privileges already dropped. In the simple MPM this is now different in general (we are running with root priviledges here). But as mod_unixd registers an APR_HOOK_FIRST hook this will not make a difference for most modules as their child_init hooks are still run with the privileges already dropped. As said just a remark and no comment as I haven't made up my mind so far if this is good or bad. Yup, I want to make a new hook, 'drop_privileges', and move most of mod_unixd to using it -- and then restore the existing behavior to child_init. -Paul
Re: MPMs, COW vs Child Process Spawning
On 10/29/2008 08:40 PM, Paul Querna wrote: Jorge Schrauwen wrote: I think for a large configurations, the copy on write is a significant optimisation - you can have large numbers of processes, and a large configuration, and get away with it, as practically the configuration is only memory resident once. I think it would be important to still support both, but certainly the code to support both shouldn't be at all complex. Perhaps the choice of which to choose could be configurable, so that Leopard users could choose config via pipe. If you are going to implement both methodes... fork() should be used and exec and pipe the config as a fallback. Well, part of the problem is that many current apache modules assume that the parent and child are fork'ed from one another -- this is a wrong assumption of course, since,it doesn't work on win32 that way -- but most of those modules are win32 only of course. If we do this on unix, we will break all of those modules. Of course, maybe that is a good thing, since then they would be ported forward and work on win32 too. I guess this would be a huge problem for making simple MPM the default MPM in 2.4 as this might require significant changes to the modules that go far beyond recompiling. So I would say that we should implement both and have it configurable (ideally at config time). Why? This allows to make performance tests and compare the difference between fork and non fork in different configurations. If it turns out that keeping both implementations is a PITA and that there is no notable gain in using fork we can drop fork off in the next major release after 2.4. This also gives the module authors more time to adjust themselves to a non fork MPM even if they don't work under Windows. Regards Rüdiger
Re: MPMs, COW vs Child Process Spawning
One of the things I've noticed on a practical level, is that forked children in worker wind up being linearized within themselves to some extent. Think of how the buffered logs work in mod_log_config (one buffer protected by a mutex). (I can't think of the correct term for it right now. Basically every thread is waiting on the same mutex eventually.) This is seen in other modules... The fork gets around this somewhat, as there are multiple mutexes independently locked/unlocked. If we have one multi-threaded process, this will force us to think about the performance ramifications of these uses of single mutexes. For mod_log_config, for example, a queue with a single writer thread may be the answer. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: MPMs, COW vs Child Process Spawning
On 10/29/08 3:40 PM, Paul Querna [EMAIL PROTECTED] wrote: Of course, maybe that is a good thing, since then they would be ported forward and work on win32 too. Can you delete open files in win32 yet?? If not, most of my stuff will not port... -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Paul Querna wrote: FWIW, I don't believe in latest and greatest linux distro as a good measure, but I do believe that there are only a few platforms that we should make design decisions around: - Linux 2.6 - FreeBSD 7 - Solaris 10 - Windows Vista If something is *fast* or *good* and can be done on all of the above platforms, I would argue we should do it from a design perspective, and I'm very much opposed to limiting how we design stuff based on the constraints of other less popular operating systems, cf epoll/kqueue/event ports. I think we shouldn't forget that we have MPMs - if we need to support a non mainstream platform, at the very least make sure that at least one functional and acceptable alternative MPM exists for that platform. Many of the obscure platforms can be potentially be embedded devices, that see far greater but ultimately invisible deployment than the traditional public facing webserver does. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: MPMs, COW vs Child Process Spawning
Akins, Brian wrote: One of the things I've noticed on a practical level, is that forked children in worker wind up being linearized within themselves to some extent. Think of how the buffered logs work in mod_log_config (one buffer protected by a mutex). (I can't think of the correct term for it right now. Basically every thread is waiting on the same mutex eventually.) This is seen in other modules... The fork gets around this somewhat, as there are multiple mutexes independently locked/unlocked. I don't think the intention would be to use a single process on Unix -- we would still spawn multiple children -- they would just be created using fork+exec of the httpd binary, rather than just fork. -Paul
Re: AuthzMergeRules blocks everything in default configuration
Dan Poirier wrote: I like the idea of replacing ON with AND and OR. It would not only provide more control, but make it explicit what kind of merging was going to happen. I have mixed thoughts about changing the default to OFF. Cons: That would mean every container directive would have to specify some sort of access control (or at least AuthzMergeRules AND) or it'd be wide open, right? I don't think so; at least, that's not what I was intending. Rather, something much like 2.2's behaviour: containers that don't specify any authz are simply protected by the nearest container merged ahead of them that does specify authz. I'm hoping to put this thread to bed shortly with the patches available here: http://people.apache.org/~chrisd/patches/httpd_authnz_configs/ My intent is to finish up the necessary documentation changes and get everything committed to trunk in the next few days. (Fingers crossed!) In the meantime, an overview follows. Many, many thanks are due to Brad Nicholes, whose massive refactoring of the authn/z system makes all of this work possible. 1) Limit and LimitExcept are made nestable, with an error in the case where all methods are configured out. There are also some tuneups related to Limit/LimitExcept being intended to contain authz configurations only and to not be functional outside Directory/ Location/etc. 2) A setting of AuthType None is allowed, which sets ap_auth_type() to NULL and thus provides a way to turn off authentication for a sub-directory. This corresponds to several convenient ways in 2.4 to turn off authorization, including Require all granted (and, at a deeper level, the new SatisfySections Off). 3) The mod_authz_core.c module is rewritten to attempt to deal with the issues discussed on this thread and the previous one, as well as those described at the end of this email. The authz_provider_list two-pronged linked lists are replaced by a tree structure that mirrors what is configured via SatisfyAll and SatisfyAny. A pair of negative authz containers are introduced, SatisfyNotAll and SatisfyNotAny, which negate their operands in the same manner as Reject. Thus we have the following table: RequireA Reject !A SatisfyAll (A B ...) SatisfyAny (A || B || ...) SatisfyNotAll !(A B ...) SatisfyNotAny !(A || B || ...) The SatisfyAny directive is renamed from SatisfyOne so as not to imply XOR-like functionality (requiring exactly one successful operand). A number of configuration-time checks are implemented to warn administrators regarding redundant or non-functional authz configurations. In particular, since the negative authz directives can not contribute meaningfully to OR-like blocks, as they can only supply neutral (AUTHZ_NEUTRAL) or false (AUTHZ_DENIED) values, they are simply not allowed in these containers. (The code should support them, though, if this check is ever removed.) Similarly, AND-like blocks without only negative authz directives also produce a configuration-time error. The MergeAuthzRules directive is renamed SatisfySections and take three possible values, Off, All, and And. The default is Off, meaning that as directory configuration sections are merged, new authz configurations replace previously merged ones. However, a directory section may specify SatisfySections All to force its predecessor's authz to be successful as well as its own. The SatisfySections Any option permits either the predecessor or current section's authz to grant the user access. Note that the setting of SatisfySections continues to be local only to the directory section it appears in; it is not inherited to subsequent sections as they are merged. The default setting of SatisfySections is Off, corresponding to traditional pre-2.4 authz logic. Within a directory section, the default logic corresponds to an AND-like block (i.e., SatisfyAll), which differs from the pre-2.4 logic whereby the first Require statement to succeed authorized the request. Legacy 2.2 configurations should, I hope, work with few or no changes as a result of these revisions. Few administrators, I hope, have configurations with multiple Require directives in a section; e.g.: Directory /foo Require group shirt Require group shoes /Directory If they do, these would need to be revised to either place all the items in a single Require directive (e.g., Require group shirt shoes) or to use a SatisfyAny section. I feel this makes the overall intent of the configuration directives clearer, since it is not apparent that the example above grants access to members of either group, not just those who are members of both. It also means that the following 2.4-style configuration makes intuitive sense, because the negative Reject directive
Re: svn commit: r708935 - in /httpd/httpd/trunk: CHANGES modules/system/ modules/system/mod_unixd.c server/mpm/simple/simple_run.c
[EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=708935view=rev Log: Introduce modules/system, and mod_unixd.c WTF? Why do we need dueling modules/arch/ and modules/system/ pragmas? Can we be consistent please? modules/arch/unix/ sounds like a perfect fit.
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
Paul Querna wrote: FWIW, I don't believe in latest and greatest linux distro as a good measure, but I do believe that there are only a few platforms that we should make design decisions around: - Linux 2.6 - FreeBSD 7 - Solaris 10 - Windows Vista the last one, there are too many IT professionals who have a very unfavorable opinion on Vista/2008 and will not be moving from 2003. I'd suggest 2003 server as a baseline, with accedental support to 2000 server. But MS just recently acknowledged that 2003 addicts will not be put out to pasture before having the opportunity to jump across to the windows next OS. So 2003 is far from dead.
Re: MPMs, COW vs Child Process Spawning
Akins, Brian wrote: On 10/29/08 3:40 PM, Paul Querna [EMAIL PROTECTED] wrote: Of course, maybe that is a good thing, since then they would be ported forward and work on win32 too. Can you delete open files in win32 yet?? If not, most of my stuff will not port... No. Delete-on-close yes. But that entails random name assignments to avoid any conflict while the file persists.
Re: AuthzMergeRules blocks everything in default configuration
On Wed, Oct 29, 2008 at 6:17 PM, Chris Darroch [EMAIL PROTECTED] wrote: The MergeAuthzRules directive is renamed SatisfySections and take three possible values, Off, All, and And. The default is Off, meaning that as directory configuration sections are merged, new authz configurations replace previously merged ones. However, a directory section may specify SatisfySections All to force its predecessor's authz to be successful as well as its own. The SatisfySections Any option permits either the predecessor or current section's authz to grant the user access. Note that the setting of SatisfySections continues to be local only to the directory section it appears in; it is not inherited to subsequent sections as they are merged. I tend to prefer something closer to the old name, especially with the Satisfy containers being optional. IOTW the sections here may not be something explicit the user can look back to. The default setting of SatisfySections is Off, corresponding to traditional pre-2.4 authz logic. Within a directory section, the default logic corresponds to an AND-like block (i.e., SatisfyAll), which differs from the pre-2.4 logic whereby the first Require statement to succeed authorized the request. Good to see the behavior default to being true to the verb. Legacy 2.2 configurations should, I hope, work with few or no changes as a result of these revisions. Few administrators, I hope, have configurations with multiple Require directives in a section; e.g.: Directory /foo Require group shirt Require group shoes /Directory More common migration breakage might be using two different authz providers there. It also means that the following 2.4-style configuration makes intuitive sense, because the negative Reject directive only has meaning in an AND-like context: Directory /foo Require group shirt Reject user noshoes /Directory When do we need the negative satisfy containers? I'm having a hard time with this one, especially with how negating Require/Reject are interpreted inside -- it almost seems like the containers should be dictating the verbs and you should just have some more agnostic match-type operator with the authz providers. -- Eric Covener [EMAIL PROTECTED]
Re: svn commit: r708935 - in /httpd/httpd/trunk: CHANGES modules/system/ modules/system/mod_unixd.c server/mpm/simple/simple_run.c
William A. Rowe, Jr. wrote: [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=708935view=rev Log: Introduce modules/system, and mod_unixd.c WTF? Why do we need dueling modules/arch/ and modules/system/ pragmas? Can we be consistent please? modules/arch/unix/ sounds like a perfect fit. I've moved it over in rr709050. -Paul
win32: bin/httpd.exe.local for DLL redirection
Touching bin/httpd.exe.local just got me out from under a restart failure with a third-party module that provide a modified copy of the openssl libraries. Upon restart mod_ssl would glom onto the already-loaded (and modified) SSL libraries (and fail due to something like a missing symbol/ordinal). After creating the .local file, windows aggressively loaded the local lib as a 2nd copy. Anyone recall other problems with libraries brought in by third-party modules that might be addressed by this? Any cautions? http://msdn.microsoft.com/en-us/library/ms811700.aspx#sidebyside_topic3 Activating DLL/COM Redirection DLL/COM redirection is activated on an application-by-application basis by the presence of a .local file. The .local file is an empty file in the same directory as the application's .exe file, with the same name as the application's .exe file with .local appended to the end of the name. For example, to activate DLL/COM redirection for an application called myapp.exe, create an empty file called myapp.exe.local in the same directory where myapp.exe is installed. Once DLL/COM redirection is activated, whenever the application loads a DLL or an OCX, Windows looks first for the DLL or OCX in the directory where the application's .exe file is installed. If a version of the DLL or OCX is found in the directory where the application's .exe file is installed, the application uses it regardless of any directory path specified in the application or the registry. If a version of the DLL or OCX is not found in the directory where the application's .exe file is installed, the normal search path or server path is used. -- Eric Covener [EMAIL PROTECTED]
Re: AuthzMergeRules blocks everything in default configuration
Eric Covener wrote: I tend to prefer something closer to the old name, especially with the Satisfy containers being optional. IOTW the sections here may not be something explicit the user can look back to. (Maybe IOW, in other words? :-) They should be: since Directory and friends all function as SatisfyAll, everything is always a section of some type. I could live with SatisfyOnMerge or something similar, but I'd like Satisfy in there somewhere to clarify the relationship with both the legacy Satisfy and the new Satisfy* blocks. Directory /foo Require group shirt Require group shoes /Directory More common migration breakage might be using two different authz providers there. Yes, and in that case, adding a SatisfyAny would be needed. Or, changing the default, which is simple. I'm inclined to commit as written, and if it looks like this is a sticking point, change it. That should be trivial, since SatisfySections Any creates exactly the same thing (during a per-dir merge), so the code paths are all tested already. When do we need the negative satisfy containers? I'm having a hard time with this one, especially with how negating Require/Reject are interpreted inside -- it almost seems like the containers should be dictating the verbs and you should just have some more agnostic match-type operator with the authz providers. I suppose the most likely case might be something like: Directory /humans_and_friendlies_only Require valid-user SatisfyNotAll Require group alien SatisfyAny Require group hostile Require group neutral Require group noninterventionist /SatisfyAny /SatisfyNotAll /Directory so aliens are OK, unless they're in one or more of a set of other groups. Presumably you can't just say Reject group alien at the top level because some aliens are OK, nor can you say Reject group hostile at the top level, because some hostiles are human. Probably makes the most sense with complex LDAP setups where people belong to lots of overlapping categories. I think negated sections are pretty clear and have some utility; at a minimum, providing the ability to negate a single match (i.e., Reject) but no equivalent negation operator at a higher level makes for some odd constructions which can be more clearly expressed with higher-level negation. It's the equivalent of negated parenthetical constructions in logical expressions, like !(A B). As you note, it's a little counter-intuitive to be using Require/Reject in these locations -- something like Match and NotMatch might make everything clearer. I'm happy to consider such a thing; I think I'll get the commit in first and then we can adjust further. The main reason to keep Require, of course, is backward compatibility. But we could set that up to work like Match, say, and throw an error unless it's used in a naked context (outside of any Satisfy*). That would be easy, and then for configurations with Satisfy* blocks, one would use Match/NotMatch inside of them. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: Simple MPM is in trunk
Paul Querna wrote on 2008-10-28 15:12 I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ ... One of the major departures is that it doesn't use any of the functions from os/unixd/, which I believe is a good long term decision, since I would like to get the MPM working on Windows. Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. Bing School of EE CS, Peking University, Beijing 100871 http://icl.pku.edu.cn/
Re: Simple MPM is in trunk
Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 I've added the Simple MPM to trunk: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/simple/ ... One of the major departures is that it doesn't use any of the functions from os/unixd/, which I believe is a good long term decision, since I would like to get the MPM working on Windows. Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Thanks, Paul
Re: Simple MPM is in trunk
Paul Querna wrote on 2008-10-30 12:10 Bing Swen wrote: Paul Querna wrote on 2008-10-28 15:12 Hope you've included 64-bit Windows in mind. Make x64 Windows a first-class citizen in httpd-2.4.x, please. How is it not a first class citizen in 2.2.x? Here are some reasons: 1. Currently Win-x64 compilation is a painstaking mission (hopeless for us), still no go to a 64-bit httpd.exe; 2. Many stock modules have no 64-bit configuration. 3. For some that compiles, there are lots of warnings of dangerous conversions. Win-64 uses P64 (only pointers are 64 bits), instead of PL64 like Linux. 4. Suboptimal network i/o and so second-class performance. Native support of IOCP (completion port) needs a mapping from requests (not connections) to worker threads, so requires httpd to do some connection scheduling (suspendable connections as discussed before). Bing
