[vote] 2.2.0 tarballs
These tarballs are Identical to 2.1.10 except for two changes: * include/ap_release.h Updated to be 2.2.0-release * The root directory was changed from httpd-2.1.10 to httpd-2.2.0 Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. I am sorry for the confusion on whole move of 2.1.10 to 2.2.0. This entire situation is completely undefined in our VERSIONING file, and hasn't ever happened before with these versioning rules. I believe the best way to move forward for everyone is to vote on these 2.2.0 tarballs. Hopefully we can all learn from this, and come up with a better VERSIONING policy by the time we do 2.4. Thanks, Paul.
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
Roy T. Fielding wrote: > and that is just what goes inside the tarball. We also have to update the > STATUS files, the website (I see Paul has started that), create docs-2.2, > and all of the other things people will remember as soon as we cross the > tarball threshold. FWIW, docs-2.2 already works on the website: http://httpd.apache.org/docs/2.2/
Documentation for 2.2.0, was Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
Roy T. Fielding wrote: >> What documentation are you talking about? > > ABOUT_APACHE Hasn't been updated since 2002. What does it have to do with a 2.2.0 release? > CHANGES What needs to be added or changed here? It notes the changes between versions. Seems fine to me. > docs/manual/* Already updated by lots of people. It has the version numbers fixed. What exactly do you think needs to be updated? > INSTALL > LAYOUT > README Already has updated URLs. > */*/README After a quick look, I didn't see anything needing updating in these: build/pkg/READMEmodules/experimental/README docs/error/README modules/ssl/README docs/icons/README modules/test/README modules/debug/READMEsrclib/pcre/README > include/ap_release.h > include/ap_mmn.h (probably okay as is) Yes, these are already done. -Paul
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
On Nov 28, 2005, at 8:07 PM, Justin Erenkrantz wrote: On Mon, Nov 28, 2005 at 07:54:24PM -0800, Roy Fielding wrote: What rules are you talking about? GA just means it isn't alpha or beta -- it has nothing whatsoever to do with the version number. 2.2 is now our STABLE branch, not our GA branch. See VERSIONING. I've seen it. 2.2.0 is our stable branch. I believe the vote indicates that the 2.2.0 release should match the code in 2.1.10 modulo the changes necessary to bump the version and update the documentation. However, nobody bypasses our release voting procedure just because they committed some document in CVS. Release votes are on completed, verifiable, signed source tar balls. What documentation are you talking about? ABOUT_APACHE CHANGES docs/manual/* INSTALL LAYOUT README */*/README include/ap_release.h include/ap_mmn.h (probably okay as is) and that is just what goes inside the tarball. We also have to update the STATUS files, the website (I see Paul has started that), create docs-2.2, and all of the other things people will remember as soon as we cross the tarball threshold. I mentioned those on our trip to Wells Fargo last week. I would have fixed them myself by now, but I made the mistake of updating my OS X 10.3.9 to 10.4.3 and Xcode 2.2 first, which led to three wasted days trying to fix lame fink bugs instead. In any case, we vote on complete source tarballs, not some expectation of a tag. There can't be any 2.2.0 release votes yet because it doesn't exist as a released tarball, nor can it exist until we have updated the docs. Yes, and we voted on the tarball contents which would be identical to 2.1.10. The only change is the release number inside ap_release.h. I don't consider that a material change that would alter my vote. So if I were to go the website and cp 2.1.10.tar* 2.2.0.tar* you wouldn't change your vote on that copy? You wouldn't mind that the tarball has ap_version wrong, the docs were last updated in 2002, and we would need to do a 2.2.1 to clean that trivial stuff up? I am not asking you to change your vote once a 2.2.0 tarball is created. I am telling you that you can't vote on 2.2.0 until a tarball is created that calls itself 2.2.0 and thus is available for review. I refuse to believe that anyone on the PMC has reviewed a release package that hasn't even been packaged yet. Feel free to veto any technical change that would cause 2.2.0 to differ significantly from 2.1.10. Feel free to make your vote on 2.2.0 on the basis of a recursive diff between the two tarball packages. The majority of votes cast were for GA. At least to me and Rich (and likely others), that implied 2.2.0. A few people (but not enough to alter the majority) specifically said that they would not vote for 2.2.0. -- justin The only vote I saw was a 2.1.10 release vote and a statement of intention to make 2.2.0 match the code in 2.1.10. That does not imply 2.2.0 is being released based on that vote, which is patently absurd. If you think anything in our guidelines implies such a thing, then please point it out so that I can delete it. Roy
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
On Mon, Nov 28, 2005 at 07:54:24PM -0800, Roy Fielding wrote: > What rules are you talking about? GA just means it isn't alpha or > beta -- it > has nothing whatsoever to do with the version number. 2.2 is now our > STABLE > branch, not our GA branch. See VERSIONING. > >I don't intend to release a 2.2.0 tarball without another vote. > >They will be identical to the 2.1.10 tarballs, except for the > >version number. (give me a few more minutes and they will be posted). > > Please don't do that. Change the version to 2.0.0-dev and then give > people > like me time to go in and edit the documentation (which is kinda hard > for > me to do at the moment because fink blew away my svn install and I can't > build it any more). We have two weeks before ApacheCon, so there is > no rush. What documentation are you talking about? > In any case, we vote on complete source tarballs, not some > expectation of > a tag. There can't be any 2.2.0 release votes yet because it doesn't > exist > as a released tarball, nor can it exist until we have updated the docs. Yes, and we voted on the tarball contents which would be identical to 2.1.10. The only change is the release number inside ap_release.h. I don't consider that a material change that would alter my vote. Our goal with VERSIONING is to *never* have 2.2.0-dev. We go straight to GA status with 2.2.0-final after 2.1.x. This has been the plan we've discussed for the last three years here on [EMAIL PROTECTED] > No, it isn't -- you said that it was a vote to release 2.1.10. I Paul precisely described what he was going to do in his vote email. I wish you had raised your concerns before rather than after the fact. > assumed > that meant you were going to bump the version number in CVS. There were > several people who said they were +1 on 2.1.10 and NOT 2.2.0, and our > voting guidelines have never allowed a release vote to take place before > the release was even prepared. The majority of votes cast were for GA. At least to me and Rich (and likely others), that implied 2.2.0. A few people (but not enough to alter the majority) specifically said that they would not vote for 2.2.0. -- justin
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
On Nov 28, 2005, at 6:13 PM, Paul Querna wrote: Roy T. Fielding wrote: On Nov 28, 2005, at 5:53 PM, [EMAIL PROTECTED] wrote: Author: pquerna Date: Mon Nov 28 17:53:31 2005 New Revision: 349582 URL: http://svn.apache.org/viewcvs?rev=349582&view=rev Log: Tag 2.2.0 from 2.1.10 tag to prepare for the 2.2.0 release What? No, sorry, -1. Your vote was on releasing 2.1.10. You should be releasing 2.1.10 to the public as GA. 2.2.0 is different -- it requires new documentation and a new tarball, and thus new votes. Our rules also say that we cannot release 2.1.10 as GA. The next GA release should be called 2.2.0. What rules are you talking about? GA just means it isn't alpha or beta -- it has nothing whatsoever to do with the version number. 2.2 is now our STABLE branch, not our GA branch. I don't intend to release a 2.2.0 tarball without another vote. They will be identical to the 2.1.10 tarballs, except for the version number. (give me a few more minutes and they will be posted). Please don't do that. Change the version to 2.0.0-dev and then give people like me time to go in and edit the documentation (which is kinda hard for me to do at the moment because fink blew away my svn install and I can't build it any more). We have two weeks before ApacheCon, so there is no rush. In any case, we vote on complete source tarballs, not some expectation of a tag. There can't be any 2.2.0 release votes yet because it doesn't exist as a released tarball, nor can it exist until we have updated the docs. If you have a better way to manage the once-every-3 year changeover from development to stable branches, please share it. This is exactly what I said I would do in the [vote] thread for 2.1.10. No, it isn't -- you said that it was a vote to release 2.1.10. I assumed that meant you were going to bump the version number in CVS. There were several people who said they were +1 on 2.1.10 and NOT 2.2.0, and our voting guidelines have never allowed a release vote to take place before the release was even prepared. Roy
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Erenkrantz wrote: > On Mon, Nov 28, 2005 at 05:59:29PM -0800, Roy Fielding wrote: > >>What? No, sorry, -1. Your vote was on releasing 2.1.10. You should be >>releasing 2.1.10 to the public as GA. 2.2.0 is different -- it requires >>new documentation and a new tarball, and thus new votes. > > > But, um, we can't do that under our versioning rules. Only 2.2.x can be > called GA. > > (The docs in the 2.1.10 tarball should not need to be changed as it > already reports itself as 2.2 there.) > > My vote (and I believe the intent of the folks who voted for GA status) > was specifically for allowing this tarball to be called 2.2.0. -- justin Hmm. That's what I thought I was voting on. And I certainly understood that Paul meant that too. - -- Rich Bowen [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDi7lsXP03+sx4yJMRAg4/AJ9xviNYdgLQEiTCOIi5kOPhv0LRHACgiYjk HhfyBklUpylwn8fI4WTJ6RU= =yi3N -END PGP SIGNATURE-
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
Roy T. Fielding wrote: On Nov 28, 2005, at 5:53 PM, [EMAIL PROTECTED] wrote: Author: pquerna Date: Mon Nov 28 17:53:31 2005 New Revision: 349582 URL: http://svn.apache.org/viewcvs?rev=349582&view=rev Log: Tag 2.2.0 from 2.1.10 tag to prepare for the 2.2.0 release What? No, sorry, -1. Your vote was on releasing 2.1.10. You should be releasing 2.1.10 to the public as GA. 2.2.0 is different -- it requires new documentation and a new tarball, and thus new votes. Our rules also say that we cannot release 2.1.10 as GA. The next GA release should be called 2.2.0. I don't intend to release a 2.2.0 tarball without another vote. They will be identical to the 2.1.10 tarballs, except for the version number. (give me a few more minutes and they will be posted). If you have a better way to manage the once-every-3 year changeover from development to stable branches, please share it. This is exactly what I said I would do in the [vote] thread for 2.1.10. -Paul
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
On Mon, Nov 28, 2005 at 05:59:29PM -0800, Roy Fielding wrote: > What? No, sorry, -1. Your vote was on releasing 2.1.10. You should be > releasing 2.1.10 to the public as GA. 2.2.0 is different -- it requires > new documentation and a new tarball, and thus new votes. But, um, we can't do that under our versioning rules. Only 2.2.x can be called GA. (The docs in the 2.1.10 tarball should not need to be changed as it already reports itself as 2.2 there.) My vote (and I believe the intent of the folks who voted for GA status) was specifically for allowing this tarball to be called 2.2.0. -- justin
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
On Nov 28, 2005, at 5:53 PM, [EMAIL PROTECTED] wrote: Author: pquerna Date: Mon Nov 28 17:53:31 2005 New Revision: 349582 URL: http://svn.apache.org/viewcvs?rev=349582&view=rev Log: Tag 2.2.0 from 2.1.10 tag to prepare for the 2.2.0 release What? No, sorry, -1. Your vote was on releasing 2.1.10. You should be releasing 2.1.10 to the public as GA. 2.2.0 is different -- it requires new documentation and a new tarball, and thus new votes. Roy
Re: [VOTE] 2.1.10 as GA
Paul Querna wrote: > Tarballs available from: > > http://people.apache.org/~pquerna/dev/httpd-2.1.10/ > > Please test and vote on releasing 2.1.10 as STABLE/General Availability. For the record, +1 for GA. Tested on Solaris 10/x86, FreeBSD 5.4/x86, NetBSD 2.0/x86, (Debian) Linux 2.6/x86, (RHEL4) Linux 2.6/x86, and Mac OS X 10.4.3/PPC. Passed httpd-test on Solaris 10 and NetBSD 2.0. Higher loads on FreeBSD 5.4 and RHEL4. -Paul
SVN/CVS repository: Sync??
Hi Listeners Would it be possible to sync the CVS repository with the SVN one for anonymous access?? (I know that most of you consider svn better than cvs...but all our environments are CVS based and we are using Eclipse extensively. First, since CVS is wery well integrated with Eclipse and second since the SVN Eclipse plugin is crashing mostly every time, we want to stay on CVS What is the proposal of the Apache group in this area?? Thank in advance for your answers Francis ANDRE
Re: [VOTE] 2.1.10 as GA
Quoting Rich Bowen <[EMAIL PROTECTED]>: I am not an Apache developer, but I think nobody said anything about caching and I am having problems using 2.1.10 as a caching proxy. I took a configuration that is working fine on 2.0 (serving a million pages/hour) and slightly modified it (removed CacheGcInterval and CacheSize) and now it is not caching at all. An apachectl configtest returns OK and the same configuration works fine on 2.0.54 and 2.0.55. I will be performing further testing on the next days. Maybe it's my configuration. Maybe not. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Orton wrote: On Sat, Nov 19, 2005 at 05:17:42PM -0800, Paul Querna wrote: Tarballs available from: http://people.apache.org/~pquerna/dev/httpd-2.1.10/ Please test and vote on releasing 2.1.10 as STABLE/General Availability. +1 tested on MacOSX (very little load, to be fair), on SuSE 9.1 Linux and on Slackware something or other. - -- Rich Bowen [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDi1tzXP03+sx4yJMRAmevAKCmU2TqJPLtySQ5HWz1WlG9Tb1MeACeOFZj zSkvw18FXPlmfJhS+e+OWIo= =zajj -END PGP SIGNATURE-
Re: [VOTE] 2.1.10 as GA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Orton wrote: > On Sat, Nov 19, 2005 at 05:17:42PM -0800, Paul Querna wrote: > >>Tarballs available from: >> >>http://people.apache.org/~pquerna/dev/httpd-2.1.10/ >> >>Please test and vote on releasing 2.1.10 as STABLE/General Availability. +1 tested on MacOSX (very little load, to be fair), on SuSE 9.1 Linux and on Slackware something or other. - -- Rich Bowen [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDi1tzXP03+sx4yJMRAmevAKCmU2TqJPLtySQ5HWz1WlG9Tb1MeACeOFZj zSkvw18FXPlmfJhS+e+OWIo= =zajj -END PGP SIGNATURE-
Re: [SPAM] [mod_python] [SPAM] ANNOUNCE: Mod_python 3.2.5 Beta
Gregory (Grisha) Trubetskoy wrote: The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the 3.2.5 Beta release mod_python. Can we make sure the final release doesn't come out as SPAM on the announce list? :-) David
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
On Mon, 28 Nov 2005, Geoffrey Young wrote: > >>or wathever. Killing AuthtType is good in that it propably lets you > >>combine different Accesses with Auth much cleaner. > >> > >>Dw > > > > Good point. After thinking about it, it seems that AuthType could be > > eliminated completely. The authentication type is already implied by Yea ho ! > > the use of the directives AuthBasicProvider, AuthDigestProvider or any > > other AuthXXXProvider that may come along in the future. Does anybody > > see a need to keep AuthType around at all under the new authentication > > architecture? > > I'm going a few rounds at the moment with a user that's confused between > ap_auth_type(r) and r->ap_auth_type, and why ap_auth_type(r) needs to be set Yep - this has taken me several years to understand myself :-) DW.
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
>>or wathever. Killing AuthtType is good in that it propably lets you >>combine different Accesses with Auth much cleaner. >> >>Dw > > > Good point. After thinking about it, it seems that AuthType could be > eliminated completely. The authentication type is already implied by > the use of the directives AuthBasicProvider, AuthDigestProvider or any > other AuthXXXProvider that may come along in the future. Does anybody > see a need to keep AuthType around at all under the new authentication > architecture? I'm going a few rounds at the moment with a user that's confused between ap_auth_type(r) and r->ap_auth_type, and why ap_auth_type(r) needs to be set at all if he's writing his own non-basic-non-digest authentication scheme. making the authtype indigenous to the provider mechanisms make a decent amount of sense to me. --Geoff
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
--On November 28, 2005 11:01:09 AM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: I'm wondering if it doesn't make sense to have two different 'hooks', one for basic, one for digest. Most providers would implement basic. Some who can handle digests could implement digest. Then the authn store could be independent of protocol. Um, have you taken a look at the provider API? -- justin
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
William A. Rowe, Jr. wrote:
Justin Erenkrantz wrote:
On Mon, Nov 28, 2005 at 08:33:14AM -0700, Brad Nicholes wrote:
other AuthXXXProvider that may come along in the future. Does anybody
see a need to keep AuthType around at all under the new authentication
architecture?
You need to be able to specify Basic or Digest, no?
I'm wondering if it doesn't make sense to have two different 'hooks', one
for basic, one for digest. Most providers would implement basic.
Some who
can handle digests could implement digest. Then the authn store could be
independent of protocol.
Some, such as auth_pam, clearly couldn't support digest, but others (I
can
even envision a ldap solution) which the server can query for a hash key,
could.
There are already two AuthN providers:
from modules/aaa/mod_auth.h:
typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);
/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
} authn_provider;
No need to make separate hooks. Any backend that doesn't support digest
just sets the get_realm_hash to NULL.
-Paul
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
Justin Erenkrantz wrote: On Mon, Nov 28, 2005 at 08:33:14AM -0700, Brad Nicholes wrote: other AuthXXXProvider that may come along in the future. Does anybody see a need to keep AuthType around at all under the new authentication architecture? You need to be able to specify Basic or Digest, no? I'm wondering if it doesn't make sense to have two different 'hooks', one for basic, one for digest. Most providers would implement basic. Some who can handle digests could implement digest. Then the authn store could be independent of protocol. Some, such as auth_pam, clearly couldn't support digest, but others (I can even envision a ldap solution) which the server can query for a hash key, could. Bill
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
>>> On 11/28/2005 at 8:49:00 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > On Mon, Nov 28, 2005 at 08:33:14AM -0700, Brad Nicholes wrote: >> other AuthXXXProvider that may come along in the future. Does anybody >> see a need to keep AuthType around at all under the new authentication >> architecture? > > One of the goals of the AAA rewrite was to be directive-backwards > compatible with 2.0's AAA. > > We can be compatible for 2.2 and remove it for 2.4 and beyond; but I don't > know if that's really worth it or not. All things considered, my choice > would be to maintain that until we bump the major: i.e. 3.0. -- justin I didn't anticipate any of this making it into 2.2 anyway and the soonest would be 2.4. The AuthType directive could remain for backwards compatibility although it would probably do nothing. Maybe even produce a message in the error log stating that it has been deprecate in favor of the AuthxxxProvider directives. Then in 3.0, it could be removed completely. Brad
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
On Mon, Nov 28, 2005 at 08:33:14AM -0700, Brad Nicholes wrote: > other AuthXXXProvider that may come along in the future. Does anybody > see a need to keep AuthType around at all under the new authentication > architecture? One of the goals of the AAA rewrite was to be directive-backwards compatible with 2.0's AAA. We can be compatible for 2.2 and remove it for 2.4 and beyond; but I don't know if that's really worth it or not. All things considered, my choice would be to maintain that until we bump the major: i.e. 3.0. -- justin
Re: 2.1 Live on Proudction Sites was Re: [VOTE] 2.1.10 as GA
Colm MacCarthaigh wrote: o.k., 76 hours later, a few dozen million requests, 10 Terabytes, a peak of 480Mbit/sec later and a concurrency of just over 5000 later, no problems. Just under 1 billion requests here. +1 for GA -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
>>> On 11/28/2005 at 4:51:21 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > So one either needs a shared 'fan out' on AAA level for the various > authType(s) - or alternatively to completely kill AuthType and let each of > the AAA modules provide something like AuthBasic on/off, AuthDigest on/off > and let each provide their -own- variant on AuthName; i.e. AuthBasicRealm > or wathever. Killing AuthtType is good in that it propably lets you > combine different Accesses with Auth much cleaner. > > Dw Good point. After thinking about it, it seems that AuthType could be eliminated completely. The authentication type is already implied by the use of the directives AuthBasicProvider, AuthDigestProvider or any other AuthXXXProvider that may come along in the future. Does anybody see a need to keep AuthType around at all under the new authentication architecture? Brad
Re: minotaur down
Nick Kew wrote: minotaur has been down for six hour now, perhaps longer. Given how many critical things live there, this is a problem. From discussion on #asfinfra (IRC), it seems (correct me if I'm wrong) that it can be accessed remotely by sufficiently privileged users even when down, but there are very few people with that privilege. Shouldn't there be an emergency backup plan, including a standby server that can be switched to for the public pages, and enough people, distributed over different timezones, equipped and privileged to switch to it? Ooo... And fairy dust. I think there should be fairy dust. ;-) See the extended discussion about hiring paid infra help and feel free to come over to [EMAIL PROTECTED] and start writing down a disaster recovery plan. By the way, there is a live backup at httpd.eu.apache.org (and similarly for most other sites), but in order to make the switch in DNS we'd need access to minotaur. Oops. Joshua.
minotaur down
minotaur has been down for six hour now, perhaps longer. Given how many critical things live there, this is a problem. From discussion on #asfinfra (IRC), it seems (correct me if I'm wrong) that it can be accessed remotely by sufficiently privileged users even when down, but there are very few people with that privilege. Shouldn't there be an emergency backup plan, including a standby server that can be switched to for the public pages, and enough people, distributed over different timezones, equipped and privileged to switch to it? -- Nick Kew
Re: proposed authz rewrite (was:Re: Suggest renaming mod_authz_host to mod_access_host)
On Sat, 26 Nov 2005, Brad Nicholes wrote: > 'authname' and 'require' are all implemented in the core module. This > just doesn't seem like the right place for them so I am considering > moving the directives to mod_authz_host. This will also facilitate the +1. Note that part of the trouble is AuthType which is kind of a core thing, or as least somethign shared among multipel AAA things. So one either needs a shared 'fan out' on AAA level for the various authType(s) - or alternatively to completely kill AuthType and let each of the AAA modules provide something like AuthBasic on/off, AuthDigest on/off and let each provide their -own- variant on AuthName; i.e. AuthBasicRealm or wathever. Killing AuthtType is good in that it propably lets you combine different Accesses with Auth much cleaner. Dw
Re: mod_so problem under OS/2
Hi Jeff, On Sun, 27 Nov 2005 13:16:12 UTC, Jeff Trawick <[EMAIL PROTECTED]> wrote: > On 11/26/05, Paul Smedley <[EMAIL PROTECTED]> wrote: > > What's happening is that it's loading all the modules that are listed > > in httpd.conf, then for some reason is trying to load them a second > > time which then fails as the library is already open. > > loading them again is normal; but they are closed/unloaded in-between Ahh ok - that gives me somewhere to go look that might be falling over. Thanks for the clue. -- Cheers, Paul.
