Re: httpd win64 binaries
On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. That's not it. The problem is MS's creation. We can either ship an 'official' msvcrt.dll based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008 or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an approach to a C runtime. Now that you mention it I do seem to vaguely remember something about this. So unless the MS gets there act together (which I doubt will happen in anytime soon) we won't see any 64-bit binaries? I'm likely to ship that DDK built flavor if only to help ensure compatibility, and let the Studio team know that they don't know what they are doing. They deliver a fun product for building something. I know, I used it almost for 2 decades. So selecting a version that is most popular say 2005(sp1) and only using that one is out of the question? They are entirely clueless at delivering a product to be used across multiple developers from multiple organizations to accomplish multiple purposes. They just can't grok that much multiplicity, and observe the central MS tenant of forcing to upgrade early and upgrade often. This isn't compatible with open source binaries. Just look at how frequently gcc is willing to bump the ver major like next to never. But I have to agree, MS's vs 2005+ series is a mess with all the .manifest and .local and bah! ~Jorge
Re: httpd win64 binaries
Jorge Schrauwen [EMAIL PROTECTED] wrote on 2008-11-3 16:26 On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote: Jorge Schrauwen wrote: The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. That's not it. The problem is MS's creation. We can either ship an 'official' msvcrt.dll based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008 or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an approach to a C runtime. Now that you mention it I do seem to vaguely remember something about this. So unless the MS gets there act together (which I doubt will happen in anytime soon) we won't see any 64-bit binaries? Though we are eager to see an 'official' 64-bit Windows httpd release, but if not binaries, why shouldn't there be an x64 configured Apache.sln? It will be already great to let people have the chance to do their own x64 compilation. It was made clear that 32-bit will soon be over at the Windows server end (http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx). I guess most of us still think that Windows Server remains as an important platform for Apache. So it's really time to make this little step further. So selecting a version that is most popular say 2005(sp1) and only using that one is out of the question? Jorge's Win64 binaries already seem to work perfectly on mainstream Windows versions. Shouldn't it be able to improve to be offical? (I just found it can not load some modules built with VS005/Win008, though). Bing
Re: httpd win64 binaries
On Mon, Nov 3, 2008 at 10:23 AM, Bing Swen [EMAIL PROTECTED] wrote: Jorge Schrauwen [EMAIL PROTECTED] wrote on 2008-11-3 16:26 On Mon, Nov 3, 2008 at 8:10 AM, William A. Rowe, Jr. wrote: Jorge Schrauwen wrote: The subject of not having an official binary package was brought up. We couldn't think of a reason why not except no body wants or has the time to do it. That's not it. The problem is MS's creation. We can either ship an 'official' msvcrt.dll based, DDK-built flavor, or the crap of the month 2005 or 2005sp1 or 2008 or 2008sp1 binary. Let's face it, flavor of the week doesn't work for an approach to a C runtime. Now that you mention it I do seem to vaguely remember something about this. So unless the MS gets there act together (which I doubt will happen in anytime soon) we won't see any 64-bit binaries? Though we are eager to see an 'official' 64-bit Windows httpd release, but if not binaries, why shouldn't there be an x64 configured Apache.sln? It will be already great to let people have the chance to do their own x64 compilation. Currently there is only a .dsw and no sln's, they get generated on import. For some project on import there is a x64 platform available but not all. I'm not sure how doable that would be? If it was easy I'm sure someone (wrowe) would probably have done this already. Easiest way to do it with the current dsw/sln is to remove the project that have and x64 targets, then create a new x64 target for the entire solution. It was made clear that 32-bit will soon be over at the Windows server end (http://blogs.technet.com/windowsserver/archive/2008/10/28/announcing-windows-server-2008-r2.aspx). I guess most of us still think that Windows Server remains as an important platform for Apache. So it's really time to make this little step further. So selecting a version that is most popular say 2005(sp1) and only using that one is out of the question? Jorge's Win64 binaries already seem to work perfectly on mainstream Windows versions. Shouldn't it be able to improve to be offical? (I just found it can not load some modules built with VS005/Win008, though). I compiled them on vs2008 IIRC (not sure only boot into the vm when need to compile) Sadly the exact same version is needed or else it refuses to load. That is what wrowe mentioned above with all the minor version bumps here and there. Bing Jorge
[patch] mod_autoindex stability depends on ap_field_noparam
find_default_item passes an imperfect request_rec to find_item.
find_item calls ap_field_noparam with uninitialized memory pool (r-pool).
Though this doesn't matter since ap_field_noparam simply returns NULL when
the 2nd argument is NULL, IMHO this should be fixed.
The attached patch makes find_default_item stop create reqest_rec.
static char *find_item(request_rec *r, apr_array_header_t *list, int path_only)
{
const char *content_type = ap_field_noparam(r-pool, r-content_type);
[cut]
static char *find_default_item(char *bogus_name, apr_array_header_t *list)
{
request_rec r;
/* Bleah. I tried to clean up find_item, and it lead to this bit
* of ugliness. Note that the fields initialized are precisely
* those that find_item looks at...
*/
r.filename = bogus_name;
r.content_type = r.content_encoding = NULL;
return find_item(r, list, 1);
}
Index: mod_autoindex.c
===
--- mod_autoindex.c (revision 710023)
+++ mod_autoindex.c (working copy)
@@ -750,12 +750,9 @@
int isdir;
};
-static char *find_item(request_rec *r, apr_array_header_t *list, int path_only)
+static char *find_item_core(const char *content_type_noparam, const char
*content_encoding,
+const char *path, apr_array_header_t *list, int
path_only)
{
-const char *content_type = ap_field_noparam(r-pool, r-content_type);
-const char *content_encoding = r-content_encoding;
-char *path = r-filename;
-
struct item *items = (struct item *) list-elts;
int i;
@@ -775,8 +772,8 @@
else if (!path_only) {
if (!content_encoding) {
if (p-type == BY_TYPE) {
-if (content_type
- !ap_strcasecmp_match(content_type,
+if (content_type_noparam
+ !ap_strcasecmp_match(content_type_noparam,
p-apply_to)) {
return p-data;
}
@@ -796,21 +793,19 @@
return NULL;
}
+static char *find_item(request_rec *r, apr_array_header_t *list, int path_only)
+{
+return find_item_core(ap_field_noparam(r-pool, r-content_type),
r-content_encoding, r-filename, list, path_only);
+}
+
#define find_icon(d,p,t) find_item(p,d-icon_list,t)
#define find_alt(d,p,t) find_item(p,d-alt_list,t)
#define find_header(d,p) find_item(p,d-hdr_list,0)
#define find_readme(d,p) find_item(p,d-rdme_list,0)
-static char *find_default_item(char *bogus_name, apr_array_header_t *list)
+static char *find_default_item(const char *bogus_name, apr_array_header_t
*list)
{
-request_rec r;
-/* Bleah. I tried to clean up find_item, and it lead to this bit
- * of ugliness. Note that the fields initialized are precisely
- * those that find_item looks at...
- */
-r.filename = bogus_name;
-r.content_type = r.content_encoding = NULL;
-return find_item(r, list, 1);
+return find_item_core(NULL, NULL, bogus_name, list, 1);
}
#define find_default_icon(d,n) find_default_item(n, d-icon_list)
Re: httpd win64 project sources/makefiles [was:...binaries]
William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM: But studio (or eclipse or codewarrior or [name your IDE]) users would appreciate a perspective into the sources. The IDE-accessible nature of the original Win32 port is what made it so easy for me to jump in, understand and substantially refactor the win32 support. Without the IDE view, would I have done that? Maybe - but at that time in my development patterns - more likely not. Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. I'm still getting my head around how all the parts of Apache work together, and would love to be able to dive into it using Eclipse and explore. The advantage of Eclipse would be that it's more cross-platform than most of the alternatives that I'm aware of. Re: windows, aren't there one or more ports of gcc? Would something like that be worth considering as a more stable build solution than MS's tools? Dan
Re: httpd win64 project sources/makefiles [was:...binaries]
William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM: Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? I'm thinking about something like CMake, which is able to target the following environments on Windows : # Borland Makefiles # MSYS Makefiles # MinGW Makefiles # NMake Makefiles # Unix Makefiles # Visual Studio 6 # Visual Studio 7 # Visual Studio 7 .NET 2003 # Visual Studio 8 2005 # Visual Studio 8 2005 Win64 # Visual Studio 9 2008 # Visual Studio 9 2008 Win64 # Watcom WMake # CodeBlocks - MinGW Makefiles # CodeBlocks - Unix Makefiles # Eclipse CDT4 - MinGW Makefiles # Eclipse CDT4 - NMake Makefiles # Eclipse CDT4 - Unix Makefiles -- Marc Noirot http://www.apachefrance.com/
Re: httpd win64 project sources/makefiles [was:...binaries]
Dan Poirier [EMAIL PROTECTED] wrote on 2008-11-3 21:13 William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM: Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. Re: windows, aren't there one or more ports of gcc? Would something like that be worth considering as a more stable build solution than MS's tools? There is a runtime library issue. Most GCC ports do not generate object code that can be linked with the necessary WinAPI runtime lib's. e.g, httpd needs to link to lots of MS C startup libraris to use the file system, socket API, IOCP, etc. Bing
Re: httpd win64 project sources/makefiles [was:...binaries]
Marc Noirot [EMAIL PROTECTED] wrote on 2008-11-3 22:06 William A. Rowe, Jr. said the following on 11/03/2008 07:32 AM: Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? I'm thinking about something like CMake, which is able to target the following environments on Windows : # Borland Makefiles # MSYS Makefiles # MinGW Makefiles # NMake Makefiles # Unix Makefiles # Visual Studio 6 # Visual Studio 7 # Visual Studio 7 .NET 2003 # Visual Studio 8 2005 # Visual Studio 8 2005 Win64 # Visual Studio 9 2008 # Visual Studio 9 2008 Win64 # Watcom WMake # CodeBlocks - MinGW Makefiles # CodeBlocks - Unix Makefiles # Eclipse CDT4 - MinGW Makefiles # Eclipse CDT4 - NMake Makefiles # Eclipse CDT4 - Unix Makefiles -- Marc Noirot This seems overwhelming. So it seems possible for httpd to have a one-to-fit-all IDE project file generator? Then everyone will have a happy ending... Bing
Re: httpd win64 project sources/makefiles [was:...binaries]
Jorge Schrauwen wrote: I compiled them on vs2008 IIRC (not sure only boot into the vm when need to compile) Sadly the exact same version is needed or else it refuses to load. That is what wrowe mentioned above with all the minor version bumps here and there. Precisely. Also note; VC2008 studio file cannot load in studio 2005. This might also be true of SP bumps. Today, it's VC6 dsw/dsp's only because that was the last version able to export a set of non-studio Makefiles. If we eliminate the need to export win32's makefiles, we eliminate dsp's altogether. So as far as .sln's are concerned, if we can emit, from our build schema, either .vcproj elements or makefiles or both, then we can forever drop VC6 files. VC6 certainly would still compile, but using the command line. I can't seriously believe that we should support the IDE itself forever. But studio (or eclipse or codewarrior or [name your IDE]) users would appreciate a perspective into the sources. The IDE-accessible nature of the original Win32 port is what made it so easy for me to jump in, understand and substantially refactor the win32 support. Without the IDE view, would I have done that? Maybe - but at that time in my development patterns - more likely not. Lets look to supporting [name your favorite IDE] as a bigger picture item not specific to windows, and to transition away from .dsp for the build/ide view support. Bill
Re: svn commit: r709993 - in /httpd/httpd/trunk: include/ modules/arch/unix/ server/ server/mpm/experimental/event/ server/mpm/prefork/ server/mpm/simple/ server/mpm/worker/
On Nov 2, 2008, at 9:47 PM, Paul Querna wrote: [EMAIL PROTECTED] wrote: Author: niq Date: Sun Nov 2 16:46:54 2008 New Revision: 709993 URL: http://svn.apache.org/viewvc?rev=709993view=rev Log: Switch all unix MPMs to use drop_privileges hook (mod_unixd) for startup and add a flag to prevent running without any module taking responsibility for managing system privileges! +/* register modules that undertake to manage system security */ +extern int sys_privileges; . +++sys_privileges; return OK; -0.98 No more global variables :( +1 on the -0.98
Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/
On Nov 2, 2008, at 1:04 PM, Justin Erenkrantz wrote: On Thu, Oct 30, 2008 at 6:06 AM, Jim Jagielski [EMAIL PROTECTED] wrote: I tend to agree... as long as the architectural design doesn't prevent people from creating (or keeping) MPMs, then this is all good. Believe it or not, as people on the front-lines of handling Apache setup and support for organizations can attest to, MPMs are a valued feature. I disagree. It's incredibly confusing to have compile-time definitions and inability to adjust them at run-time. I'd prefer that we remove all MPMs and teach whatever remains to be able to emulate prefork (multiple-process/single-thread) or worker (multiple-process/multiple-thread) at run-time. You miss my point. If we just have one MPM, and make it such that other MPMs are at a significant advantage, then why even have MPMs? Hardcode in simple and be done. In any case, we can pretty much do that with Worker now, as well as Simple...
Re: svn commit: r708902 - /httpd/httpd/trunk/modules/metadata/mod_expires.c
On Nov 1, 2008, at 6:54 AM, Ruediger Pluem wrote:
This causes failures in the perl framework:
t/modules/expires.t92 15 16.30% 4 10 14 17-18 22
29-30 34-
35 38 42 46 48 50
But IMHO the code is now correct after the patch and the tests are
wrong. The following
patch makes the tests pass again:
Index: t/modules/expires.t
===
--- t/modules/expires.t (Revision 707830)
+++ t/modules/expires.t (Arbeitskopie)
@@ -231,6 +231,13 @@
if ($exp_conf =~ /^([A|M])(\d+)$/) {
$exp_type = $1;
$expected = $2;
+## With modification date as base expire times can be in
the past
+## Correct behaviour for the server in this case is to set
expires
+## time equal to access time.
+if (($exp_type eq 'M')
+ ($headers{access} $headers{modified} + $expected)) {
+$expected = $headers{access} - $headers{modified};
+}
} else {
print STDERR \n\ndoom: $exp_conf\n\n;
return 0;
Comments?
Thanks! I forgot to mention that the test cases were bad, and had
intended
to fix them, but time got away from me. Thanks for following
up!
+1
Re: httpd win64 project sources/makefiles [was:...binaries]
Marc Noirot wrote: What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? +1. Binding httpd to one IDE significantly reduces the developer audience, it would help a lot if Windows could have the same autoconf ability that the Unix build has had for years. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: httpd win64 project sources/makefiles [was:...binaries]
On Nov 3, 2008, at 6:06 AM, Marc Noirot wrote: What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? I'm thinking about something like CMake ... http://lwn.net/Articles/188693/ http://www.cmake.org/ +1 But it still requires folks to do the work. Hackathon? Roy
Re: svn commit: r709708 - in /httpd/httpd/trunk: include/ap_mmn.h include/mod_auth.h modules/aaa/mod_authz_owner.c
Ruediger Pluem wrote: IMHO this requires a major bump (no problem on trunk) and not only a minor one. Thanks for catching that and the missing apr_pcalloc() in mod_authz_core.c! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: svn commit: r709553 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_authn_core.xml modules/aaa/mod_authn_core.c
Ruediger Pluem wrote: could you please split such changes into atomic commits? One issue - one commit. You also committed docs changes you didn't mention in the log message. I'm not sure if the crash fix shouldn't go into CHANGES. Plus it makes it really hard to read the diffs if you mix formating changes with functional changes. Please separate them. Yes, my apologies for that. I confess I'd hoped to cut a couple of corners because these files exist only in trunk, I wasn't planning any backports, and there seemed to be such a remarkably low level of interest in the trunk authn/z stuff. Still, I should have done a better job. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: httpd win64 project sources/makefiles [was:...binaries]
cmake seems very interesting. I'd like to help if you go that path, not sure I'll be of much use though. ~Jorge On Mon, Nov 3, 2008 at 6:42 PM, Roy T. Fielding [EMAIL PROTECTED] wrote: On Nov 3, 2008, at 6:06 AM, Marc Noirot wrote: What about going one step further and using a tool able to generate Makefiles and IDE files for [name some of your favorite IDEs] ? I'm thinking about something like CMake ... http://lwn.net/Articles/188693/ http://www.cmake.org/ +1 But it still requires folks to do the work. Hackathon? Roy
Re: AuthzMergeRules blocks everything in default configuration
Dan Poirier wrote:
I'd find it much easier to understand if we had fewer directives, and
just built up the more complicated ideas by writing boolean expressions,
which most of us already know how to cope with.
Perhaps, and the underlying code should support a range of alternative
configuration schemes; if someone wants to add an expression parser,
that should be feasible.
My own perspective was that I wanted to satisfy number of goals,
in descending order of priority:
First, and most important, I wanted to ensure default 2.2-style
authz. Imagine administrating a large mass virtual hosting service
whose customers have uploaded thousands of .htaccess files, and trying
to upgrade to 2.4. Clearly, those .htaccess files need to work exactly
as before. Even if we supplied a batch conversion script that could
find and auto-upgrade them, customers would later upload their own private
copies of their old files, thus inadvertently breaking their sites.
So, that meant an OR-like context for Require directives, and
no merging of authz configurations by default. This whole thread
started because I was trying mod_authz_dbd and noticed it didn't
work as expected because AuthzMergeRules was On (i.e., OR) by default.
(In my previous message I described switching to an AND-like default
context for Require directives, but realized before committing that
that would break with this prime directive of backwards-compatibility.)
So, if people could please test with 2.2-style authz configurations
and make sure everything works as expected, that would be superb.
Second, I wanted to simplify things a little. The revised
mod_auth.h and mod_authz_core.c have shrunk a little, and I felt I
could remove the default authn/z modules. (Having both core and
default modules for authn and authz, any of which could be compiled
out, seemed a likely source of trouble.)
Third, while looking into how mod_authz_core worked, I found
some ways to configure it that would cause unexpected results,
and while trying to fix those came to the conclusion I needed to
start over with a tree-based implementation.
Doing that and working through the implications of a non-Boolean
tri-state logic (where negating a false value results in a neutral,
not true, value) I found that adding negated authz container directives
was something that just fell out naturally.
Finally there was a certain amount of bike-shed re-painting in
the form of renaming configuration directives. I settled on
Match, MatchAll, etc. based on Eric Covener's comments.
If people dislike those names, please jump in and change them.
Or if most folks think we'd be better off without authz containers
entirely, please vote for the following patch, which simply turns all
that stuff off, leaving (I hope) a fairly clean core authz implementation
that supports default 2.2-style behaviour and is extensible down the road,
should that be desired.
Chris.
Index: mod_authz_core.c
===
--- mod_authz_core.c(revision 710120)
+++ mod_authz_core.c(working copy)
@@ -405,6 +405,7 @@
return NULL;
}
+#ifdef AUTHZ_CORE_CONTAINERS
static const char *add_authz_section(cmd_parms *cmd, void *mconfig,
const char *args)
{
@@ -534,6 +535,7 @@
return NULL;
}
+#endif /* AUTHZ_CORE_CONTAINERS */
static int authz_core_check_section(apr_pool_t *p, server_rec *s,
authz_section_conf *section, int is_conf)
@@ -634,6 +636,7 @@
specifies legacy authorization directives
of which one must pass
for a request to suceeed),
+#ifdef AUTHZ_CORE_CONTAINERS
AP_INIT_RAW_ARGS(Match, add_authz_provider, NULL, OR_AUTHCFG,
specifies authorization directives that must pass
(or not) for a request to suceeed),
@@ -656,6 +659,7 @@
controls how a Directory, Location, or similar
directive's authorization directives are combined with
those of its predecessor),
+#endif /* AUTHZ_CORE_CONTAINERS */
{NULL}
};
Re: svn commit: r709839 - in /httpd/httpd/trunk: ./ build/ modules/aaa/modules/arch/netware/ os/netware/ os/win32/
On 11/1/2008 at 10:21 PM, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Author: chrisd Date: Sat Nov 1 21:21:48 2008 New Revision: 709839 URL: http://svn.apache.org/viewvc?rev=709839view=rev Log: Remove mod_authn_default and mod_authz_default. Note: I've attempted to work through the Windows and Netware build files, but if those with such systems could repair any damage, that would be appreciated. Removed: httpd/httpd/trunk/modules/aaa/mod_authn_default.c httpd/httpd/trunk/modules/aaa/mod_authn_default.dsp httpd/httpd/trunk/modules/aaa/mod_authz_default.c httpd/httpd/trunk/modules/aaa/mod_authz_default.dsp httpd/httpd/trunk/modules/arch/netware/mod_authn_default.def httpd/httpd/trunk/modules/arch/netware/mod_authz_default.def Modified: httpd/httpd/trunk/Apache.dsw httpd/httpd/trunk/CHANGES httpd/httpd/trunk/Makefile.win httpd/httpd/trunk/NWGNUmakefile httpd/httpd/trunk/build/installwinconf.awk httpd/httpd/trunk/build/mkconfNW.awk httpd/httpd/trunk/modules/aaa/config.m4 httpd/httpd/trunk/os/netware/modules.c httpd/httpd/trunk/os/win32/BaseAddr.ref I haven't tried out the new authnz directives yet, but it at least builds on NetWare. Brad
Re: AuthzMergeRules blocks everything in default configuration
On 11/03/2008 08:12 PM, Chris Darroch wrote: Dan Poirier wrote: I'd find it much easier to understand if we had fewer directives, and just built up the more complicated ideas by writing boolean expressions, which most of us already know how to cope with. Perhaps, and the underlying code should support a range of alternative configuration schemes; if someone wants to add an expression parser, that should be feasible. My own perspective was that I wanted to satisfy number of goals, in descending order of priority: First, and most important, I wanted to ensure default 2.2-style authz. Imagine administrating a large mass virtual hosting service whose customers have uploaded thousands of .htaccess files, and trying to upgrade to 2.4. Clearly, those .htaccess files need to work exactly as before. Even if we supplied a batch conversion script that could find and auto-upgrade them, customers would later upload their own private copies of their old files, thus inadvertently breaking their sites. So, that meant an OR-like context for Require directives, and no merging of authz configurations by default. This whole thread started because I was trying mod_authz_dbd and noticed it didn't work as expected because AuthzMergeRules was On (i.e., OR) by default. (In my previous message I described switching to an AND-like default context for Require directives, but realized before committing that that would break with this prime directive of backwards-compatibility.) So, if people could please test with 2.2-style authz configurations and make sure everything works as expected, that would be superb. One of the authz tests breaks on trunk since a long time (I think it started to break after Brad refactored the code): t/http11/basicauth1..3 # Running under perl version 5.008008 for linux # Current time local: Mon Nov 3 20:46:36 2008 # Current time GMT: Mon Nov 3 19:46:36 2008 # Using Test.pm version 1.25 # Using Apache/Test.pm version 1.31 ok 1 not ok 2 # Failed test 2 in t/http11/basicauth.t at line 24 ok 3 FAILED test 2 Failed 1/3 tests, 66.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/http11/basicauth.t31 33.33% 2 Failed 1/1 test scripts, 0.00% okay. 1/3 subtests failed, 66.67% okay. I was hoping that your patches would fix this, but sadly they did not. From what I reviewed, the authz code should now react similar to the 2.2.x authz code, but apprently it does not. As you have crawled that deeply in the authz code you seem to be the natural person to have a look at this failing test :-). I think this would be greatly appreciated. Otherwise I think it is cool work that can be used for very complex configuration needs. Regards Rüdiger
mod_unixd troubs?
Hi -- I've been trying to get trunk to compile and run today, and if I compile it without mod_unixd (and with the worker MPM) it compiles and run, but then logs Server MUST relinquish startup privileges ... and exits. If I try to compile mod_unixd, I get compile-time warnings about conflicts with os/unix/unixd.h and unixd.c. The following hack gets it to compile without mod_unixd (not the intention, I understand) and run without exiting at startup. I'm guessing the goal is to remove os/unix/unixd.h and unixd.c? I tried that, naively, and found that the MPM wouldn't compile because it uses #include unixd.h in mpm.h, etc. Chris. Index: os/unix/unixd.c === --- os/unix/unixd.c (revision 710182) +++ os/unix/unixd.c (working copy) @@ -246,6 +246,8 @@ unixd_config.chroot_dir = NULL; /* none */ +sys_privileges_handlers(1); + /* Check for suexec */ unixd_config.suexec_enabled = 0; if ((apr_stat(wrapper, SUEXEC_BIN,
Re: mod_unixd troubs?
On Mon, 03 Nov 2008 14:49:21 -0800 Chris Darroch [EMAIL PROTECTED] wrote: Hi -- I've been trying to get trunk to compile and run today, and if I compile it without mod_unixd (and with the worker MPM) it Thanks for the heads-up. Yes, there's more needs doing for the prefork/worker/event MPMs. Hacking on it now, but breakage is likely for a while longer. -- Nick Kew
Re: mod_unixd troubs?
On Tue, 4 Nov 2008 00:27:24 + Nick Kew [EMAIL PROTECTED] wrote: On Mon, 03 Nov 2008 14:49:21 -0800 Chris Darroch [EMAIL PROTECTED] wrote: Hi -- I've been trying to get trunk to compile and run today, and if I compile it without mod_unixd (and with the worker MPM) it Thanks for the heads-up. Yes, there's more needs doing for the prefork/worker/event MPMs. Hacking on it now, but breakage is likely for a while longer. r711146 fixes the worker MPM, by removing the duplicated stuff. TBD: make it build mod_unixd when prefork/worker/event MPM is selected - still need to configure that explicitly. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: AuthzMergeRules blocks everything in default configuration
Ruediger Pluem wrote:
I was hoping that your patches would fix this, but sadly they did not.
Ironically, the problem appears to have little to do with authz,
but rather authn. The test httpd logs show it's failing to find
an htpasswd-type file in which to check the user's login and password.
That's because there's no AuthBasicProvider in the test config, and
the code -- since way back, I think -- defaults to the file authn
provider.
Looking back in SVN it seems like that should have been the
behaviour for quite a number of years, but I confess I didn't dig
too deeply. Nor did I try out the test suite with 2.2.x to see
if it succeeds as-is, and if so, why. If it does, my hunch would
be that it succeeds because the suite doesn't actually use the normal
authn/z providers, but rather supplies its own module called mod_authany.c.
That module contains two different alternative set of functions
based on an #if AP_MODULE_MAGIC_AT_LEAST(20060110, 0) which corresponds
to, I think, an attempt to just get it to compile after the authn/z
refactoring in trunk. The log comment for r375595 is:
- attempt to adapt for trunk aaa changes; this doesn't work
but it does at least compile - not sure whether the problem
is in this code or the aaa code.
At any rate, my guess would be that it works (if it does) with
2.2.x because the module supplies its own raw check_user_id (i.e., authn)
and auth_checker (i.e., authz) hook functions which run as APR_HOOK_FIRST
and probably bypass all the stuff in the usual APR_HOOK_MIDDLE hook
functions of mod_auth_basic and mod_authz_file. So the fact
that it doesn't specify any AuthBasicProvider never comes up because
it bypasses mod_auth_basic entirely. Just a guess.
At any rate, the patch below makes it run with trunk, and
properly too, in the sense that it uses mod_authn_core and
mod_authz_core to do the heavy lifting and just supplies a tiny
pair of authn/z providers. But, this isn't really a perfect
solution because it's not really correct to put the authn provider
into the AP_MODULE_MAGIC_AT_LEAST(20060110, 0) block, since it
doesn't (I think) have anything in particular to do with that
change. Sorry not to spend more time on this.
Chris.
Index: mod_authany.c
===
--- mod_authany.c (revision 710145)
+++ mod_authany.c (working copy)
@@ -5,6 +5,7 @@
require user any-user
AuthType Basic
AuthName authany
+ AuthBasicProvider any
/Location
#endif
@@ -19,6 +20,18 @@
#include ap_provider.h
#include mod_auth.h
+static authn_status authn_check_password(request_rec *r, const char *user,
+ const char *password)
+{
+return strtrue(r-user) strcmp(r-user, guest) == 0
+? AUTH_GRANTED : AUTH_DENIED;
+}
+
+static const authn_provider authn_any_provider =
+{
+authn_check_password
+};
+
static authz_status any_check_authorization(request_rec *r,
const char *requirement)
{
@@ -28,11 +41,13 @@
static const authz_provider authz_any_provider =
{
-any_check_authorization,
+any_check_authorization
};
static void extra_hooks(apr_pool_t *p)
{
+ap_register_provider(p, AUTHN_PROVIDER_GROUP,
+ any, 0, authn_any_provider);
ap_register_provider(p, AUTHZ_PROVIDER_GROUP,
user, 0, authz_any_provider);
}
Re: svn commit: r709839 - in /httpd/httpd/trunk: ./ build/ modules/aaa/modules/arch/netware/ os/netware/ os/win32/
Brad Nicholes wrote: I haven't tried out the new authnz directives yet, but it at least builds on NetWare. Thanks -- glad to know it compiles, at least! Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
