Re: client_socket bogosity...
> The create_connection hook has a fatal design flaw. create_conn is run before > ap_update_vhost_given_ip(), which means that it is impossible to install input and output > filters based on vhost info. > More concisely, it is now impossible to install filters in place of CORE_IN and CORE_OUT based on vhost config. Bill
Re: client_socket bogosity...
Bill Stoddard wrote: > The create_connection hook has a fatal design flaw. create_conn is run before > ap_update_vhost_given_ip(), which means that it is impossible to install input and >output > filters based on vhost info. > > I want to install SSL_IN and SSL_OUT filters if the request is coming in to a >vhost/port > enabled for SSL and that can't be done with the create_connection hook. > > Bill > On that point. I don't think there is any way of inserting a proxy specifc filter either, as their is now way for the hook to know what kind of request is the connection is for. > >>>One Nov. 12, Ryan committed a patch creating the create_conn hook. The >>>idea was to move >>>the client_socket out of the conn_rec presumably to make available >>> >>only to >> >>>the core_in and >>>core_out filters. However, I just found a backdoor... >>> >>>In core_create_conn() the socket is saved away thusly: >>>ap_set_module_config(net->c->conn_config, &core_module, csd); >>> >>>And whoever needs to access the socket does this: >>>apr_socket_t *csd = ap_get_module_config(f->c->conn_config, >>> >>&core_module); >> >>That hack was added because the proxy does the completely wrong thing >>with regard to handing sockets. In order to finish the Nov. 12 patch, I >>need to rip a lot of logic out of the proxy and re-implement, which I >>haven't had time to do recently. The only other module that should use >>the get_module_config hack is the perchild module, which is also doing >>to completely wrong thing with regard to sockets, but I haven't had time >>to fix that one either. >> >> >> >>>So the goal of hiding the socket is completely blown. The Nov. 11 >>> >>change >> >>>added a lot of >>>complexity to the server (hard to read/understand code) in pursuit of >>> >>a >> >>>goal that is then >>>immediately circumvented by the ap_get|set_module_config. So we made >>> >>the >> >>>server more >>>complex for no reason. >>> >>It actually isn't blown. Try writing a module that implements a non TCP >>socket, and it will work as long as you don't use the proxy or the >>perchild module. As proof, look at the fact that the Unix MPMs have >>been using that mechanism to handle the pipe_of_death. This allowed me >>to remove the ugly hacks at the beginning of the accept loop, which >>checked for the POD. >> >>Also, a big portion of the Nov 12 patch was to consolidate the accept >>functions for Unix and BeOS, which has meant far less duplicated code in >>the server. >> >> >>>I am on the verge of vetoing the Nov. 12 patch in favor of moving the >>>client_socket back >>>into the con_rec. >>> >>>Comments? >>> >>Please don't let two mis-behaved modules color your judgment on this. >>Both proxy and perchild must be re-written if they are going to be >>clean, and once that is done the stupid set_module_config can be >>removed. In fact, the server ran for over a day without the >>set_module_config, but that broke the proxy, so I added the hack to >>allow the proxy to continue to work, while I worked to solve the >>underlying problem. Unfortunately, work and some extracurricular >>activities have stopped me from contributing much code recently. >>Hopefully, I will have time to code again soon. >> >>Ryan >> >> >> > >
Re: client_socket bogosity...
The create_connection hook has a fatal design flaw. create_conn is run before ap_update_vhost_given_ip(), which means that it is impossible to install input and output filters based on vhost info. I want to install SSL_IN and SSL_OUT filters if the request is coming in to a vhost/port enabled for SSL and that can't be done with the create_connection hook. Bill > > One Nov. 12, Ryan committed a patch creating the create_conn hook. The > > idea was to move > > the client_socket out of the conn_rec presumably to make available > only to > > the core_in and > > core_out filters. However, I just found a backdoor... > > > > In core_create_conn() the socket is saved away thusly: > > ap_set_module_config(net->c->conn_config, &core_module, csd); > > > > And whoever needs to access the socket does this: > > apr_socket_t *csd = ap_get_module_config(f->c->conn_config, > &core_module); > > That hack was added because the proxy does the completely wrong thing > with regard to handing sockets. In order to finish the Nov. 12 patch, I > need to rip a lot of logic out of the proxy and re-implement, which I > haven't had time to do recently. The only other module that should use > the get_module_config hack is the perchild module, which is also doing > to completely wrong thing with regard to sockets, but I haven't had time > to fix that one either. > > > > So the goal of hiding the socket is completely blown. The Nov. 11 > change > > added a lot of > > complexity to the server (hard to read/understand code) in pursuit of > a > > goal that is then > > immediately circumvented by the ap_get|set_module_config. So we made > the > > server more > > complex for no reason. > > It actually isn't blown. Try writing a module that implements a non TCP > socket, and it will work as long as you don't use the proxy or the > perchild module. As proof, look at the fact that the Unix MPMs have > been using that mechanism to handle the pipe_of_death. This allowed me > to remove the ugly hacks at the beginning of the accept loop, which > checked for the POD. > > Also, a big portion of the Nov 12 patch was to consolidate the accept > functions for Unix and BeOS, which has meant far less duplicated code in > the server. > > > I am on the verge of vetoing the Nov. 12 patch in favor of moving the > > client_socket back > > into the con_rec. > > > > Comments? > > Please don't let two mis-behaved modules color your judgment on this. > Both proxy and perchild must be re-written if they are going to be > clean, and once that is done the stupid set_module_config can be > removed. In fact, the server ran for over a day without the > set_module_config, but that broke the proxy, so I added the hack to > allow the proxy to continue to work, while I worked to solve the > underlying problem. Unfortunately, work and some extracurricular > activities have stopped me from contributing much code recently. > Hopefully, I will have time to code again soon. > > Ryan > >
RE: client_socket bogosity...
> On Fri, Jan 25, 2002 at 02:01:26PM -0800, Ryan Bloom wrote: > > > > Please don't let two mis-behaved modules color your judgment on > > this. > > > > Both proxy and perchild must be re-written if they are going to be > > > > clean, and once that is done the stupid set_module_config can be > > > > removed. In fact, the server ran for over a day without the > > > > set_module_config, but that broke the proxy, so I added the hack to > > > > allow the proxy to continue to work, while I worked to solve the > > > > underlying problem. > > > > > > mmm... I'd be interested to know what the solution is for > > > net_time_filter since it is using the ap_get_module_config > > > hack also. > > > > The real solution is to pass the core_net_rec structure to the NET_TIME > > filter as user-data for the filter, the same way we do for CORE_IN and > > CORE_OUT. > > You're kidding, right? The core_net_rec is private to the core. You can't > just start passing that around the server. That just breaks the > abstraction > that you've worked so hard to implement. > > No... something else needs to be figured out [for the net_time_filter]. But the net_time_filter is implemented by the core. If we really want to abstract this more, we can create a function that, given a conn_rec can set a timeout on the socket. I think I see how that can be done. Or, we can actually create a net_module, that has a spot in the c->conf_vector that is the net_rec. That module can implement the logic to set a timeout on a connection. Which is really what we want, to be able to set a timeout on a connection, not on a socket. Ryan
RE: client_socket bogosity...
> > > The real solution is to pass the core_net_rec structure to the NET_TIME > > filter as user-data for the filter, the same way we do for CORE_IN and > > CORE_OUT. > > But you'll have to play some sort of trick to do that since the > NET_TIME filter is added from the create_request hook which does > not know about core_net_rec, only core_create_conn knows about that. > I suppose some core specific magic could be played but that would > prevent any other module from running it's own net_time hook. This is why I didn't do this originally, but it wouldn't be hard to add. As long as it's just the core that knows about the core_net_rec, we are okay. I just ran out of time while doing the implementation. Ryan
Re: client_socket bogosity...
On Fri, Jan 25, 2002 at 02:01:26PM -0800, Ryan Bloom wrote: > > > Please don't let two mis-behaved modules color your judgment on > this. > > > Both proxy and perchild must be re-written if they are going to be > > > clean, and once that is done the stupid set_module_config can be > > > removed. In fact, the server ran for over a day without the > > > set_module_config, but that broke the proxy, so I added the hack to > > > allow the proxy to continue to work, while I worked to solve the > > > underlying problem. > > > > mmm... I'd be interested to know what the solution is for > > net_time_filter since it is using the ap_get_module_config > > hack also. > > The real solution is to pass the core_net_rec structure to the NET_TIME > filter as user-data for the filter, the same way we do for CORE_IN and > CORE_OUT. You're kidding, right? The core_net_rec is private to the core. You can't just start passing that around the server. That just breaks the abstraction that you've worked so hard to implement. No... something else needs to be figured out [for the net_time_filter]. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: Apache-1.3: ftp proxy woes
Fantastic. FTP proxy has been funky for some time now (but was working if hobbling in 1.3.23 drop). When I do connect in the BillR way that might wrap up the thing mostly. Chuck On Friday, January 25, 2002, at 11:33 AM, Martin Kraemer wrote: > I am currently working on modifying the FTP proxy. Several things > do not work correctly: > > * the proxy goes into "TYPE I" pretty quickly. However, binary transfers > are inappropriate for directory listings, especially when you connect > to an EBCDIC machine :-O > IMO, "TYPE I" should be sent directly before trying RETR, and should > be set back to "TYPE A" again when RETR failed and we are getting a > LISTing instead. See RFC959. > Also, the suffix ";type=[aid]" could be extended to allow for > ";type=e" > for forced EBCDIC transfer ;-) Not that I know a client which uses > it. > > * The code path thru the proxy_ftp_handler is rather convoluted. My > rewrite > funnels each return() thru a common function which cleans up, closing > BUFFs or sockets where needed. The current code has MANY returns which > do not clean up properly. This led to my Apache server running out of > children after a while (because each child kept an open FTP connection > to the ftp server). "Apachectl restart" saved the day ;-) > > * the so called "%2F" hack, which would allow a user of the proxy to > selectively start with either her home dir (ftp://user@host/) or > with the root dir of the system (by using ftp://user@host/%2f/) > is implemented in squid. Wouldn't it be nice to have it in our proxy > too? > > * Speaking of %2f: Apache's verification checks for path components > are not executed for the ftp proxy, it uses its own url encoding > and decoding, and many security checks are missing there. You can > go get ftp://user@host/%2fetc%2fpasswd or even > ftp://user@host/%2fetc%2fdefaults%2f%2e%2e%2fgroup > without any complaints by the proxy. >
CVS code on 1/25/02 | problem: segfault on startup
This is my first foray into apache 2.0 land so I'm not familiar with things.
I built glibc 2.2.5 and apache broke. I rebuilt apache and it still
broke :)
(gdb) bt
#0 apr_palloc (pool=0x813e720, size=24) at apr_pools.c:438
#1 0x4003524f in apr_array_make (p=0x813e720, nelts=30, elt_size=20) at
apr_tables.c:120
#2 0x08070e66 in parse_log_string (p=0x813e720, s=0x80c84e5 "%h %l %u
%t \"%r\" %>s %b", err=0xb4a8)
at mod_log_config.c:712
#3 0x08071738 in open_multi_logs (s=0x80fd0e0, p=0x813e720) at
mod_log_config.c:1097
#4 0x0807176a in init_config_log (pc=0x80f6600, p=0x813e720,
pt=0x8140728, s=0x80fd0e0) at mod_log_config.c:1174
#5 0x080aa5bf in ap_run_open_logs (pconf=0x80f6600, plog=0x813e720,
ptemp=0x8140728, s=0x80fd0e0) at config.c:179
#6 0x080ae580 in main (argc=1, argv=0xb5d4) at main.c:446
(gdb) up
#1 0x4003524f in apr_array_make (p=0x813e720, nelts=30, elt_size=20) at
apr_tables.c:120
120 res = (apr_array_header_t *) apr_palloc(p,
sizeof(apr_array_header_t));
(gdb) l
115 APR_DECLARE(apr_array_header_t *) apr_array_make(apr_pool_t *p,
116 int nelts, int
elt_size)
117 {
118 apr_array_header_t *res;
119
120 res = (apr_array_header_t *) apr_palloc(p,
sizeof(apr_array_header_t));
121 make_array_core(res, p, nelts, elt_size, 1);
122 return res;
123 }
124
(gdb) p p
$4 = (apr_pool_t *) 0x813e720
(gdb) p *p
$5 = {parent = 0x80f45f8, child = 0x0, sibling = 0x813e848, ref = 0x5,
cleanups = 0x813e7f0, subprocesses = 0x0, abort_fn = 0,
user_data = 0x0, tag = 0x0, allocator = 0x2, active = 0x, self
= 0x813e710,
self_first_avail = 0x813e758 "/usr/local/apache2/logs/error_log"}
Any suggestions?
David
RE: client_socket bogosity...
> prevent any other module from running it's own net_time hook. I meant net_time filter...
RE: client_socket bogosity...
> The real solution is to pass the core_net_rec structure to the NET_TIME > filter as user-data for the filter, the same way we do for CORE_IN and > CORE_OUT. But you'll have to play some sort of trick to do that since the NET_TIME filter is added from the create_request hook which does not know about core_net_rec, only core_create_conn knows about that. I suppose some core specific magic could be played but that would prevent any other module from running it's own net_time hook. Allan
RE: client_socket bogosity...
> > Please don't let two mis-behaved modules color your judgment on this. > > Both proxy and perchild must be re-written if they are going to be > > clean, and once that is done the stupid set_module_config can be > > removed. In fact, the server ran for over a day without the > > set_module_config, but that broke the proxy, so I added the hack to > > allow the proxy to continue to work, while I worked to solve the > > underlying problem. > > mmm... I'd be interested to know what the solution is for > net_time_filter since it is using the ap_get_module_config > hack also. The real solution is to pass the core_net_rec structure to the NET_TIME filter as user-data for the filter, the same way we do for CORE_IN and CORE_OUT. Ryan
RE: client_socket bogosity...
> Please don't let two mis-behaved modules color your judgment on this. > Both proxy and perchild must be re-written if they are going to be > clean, and once that is done the stupid set_module_config can be > removed. In fact, the server ran for over a day without the > set_module_config, but that broke the proxy, so I added the hack to > allow the proxy to continue to work, while I worked to solve the > underlying problem. mmm... I'd be interested to know what the solution is for net_time_filter since it is using the ap_get_module_config hack also. Allan
Re: Tagging .31 soon
"William A. Rowe, Jr." wrote: > > > I don't remember seeing a fix for the recursive subrequest loops involving > > > mod_negotiation. Did I miss it? > > Ok... this is the last priority issue I've put on my own plate prior to > another beta release. The other three issues seem closed. > > I'll fight on tommorow. Hoping you are around, Greg, if I come up with > any experimental solutions to try. yep...I'm here. My guess is that we can recreate this at will with .30 and the right URLs. I'm going to update my log replay input files to include the URLs from the 4 coredumps, plus something like http://www.apache.org/index/bogus_dir/bogus_file which has caused problems before. Greg
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
"William A. Rowe, Jr." wrote: > > > * it looks like we might be triggering some 1.3 negotiation behavior, where any > > extention under the sun is a match. We use MultiviewsMatch Handlers, so .asis > > and .cgi extentions do not need to be specified in the URI. > > Of course. This is as-desired, no? ooops, I wasn't clear. We want extensions specified by AddLanguage to match, and (since I code MultiviewsMatch Handlers) extentions specified by AddHandler. I think that's all the extensions we want to match implicitly. But looking at that backtrace, it looks like mod_negotiation might be thinking that .1, .3, etc are interesting extensions, which is what 1.3 would do, and therefore thinking that v3.1 from URI might match v3.1.1 it found by reading the builds/jakarta-tomcat/release/ directory. Greg
Re: [Apache-1.3]: URL-Escaping
On Fri, Jan 25, 2002 at 05:38:50PM +0100, Kraemer, Martin wrote: > > Or am I wrong? If I am right, then either a new T_ class must be defined in > gen_test_char, or Uh. I *AM* wrong. T_OS_ESCAPE_PATH should cause a '%' to be escaped. I must have been blind when I tried it. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: [Apache-1.3]: URL-Escaping
Sorry for all this so shortly after 1.3.23's announcement. But really, this all has hit me only yesterday, so I could not complain earlier. And when rewriting proxy_ftp, a certain stabilizing period would be good (no need rushing out a fix for a release in 3 days). Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
[Apache-1.3]: URL-Escaping
Hi again,
ap_os_escape_path() and its wrapper macro ap_escape_uri() fail to
escape a literal '%' in a path. I may be wrong, but IMHO a directory
called %dir should be url-encoded as:
%dir
Or am I wrong? If I am right, then either a new T_ class must be defined in
gen_test_char, or
while ((c = *s)) {
if (TEST_CHAR(c, T_OS_ESCAPE_PATH)) {
d = c2x(c, d);
}
else {
*d++ = c;
}
should be using
if (c == '%' || TEST_CHAR(c, T_OS_ESCAPE_PATH)) {
instead.
Protocol gurus? Anyone?
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Apache-1.3: ftp proxy woes
I am currently working on modifying the FTP proxy. Several things do not work correctly: * the proxy goes into "TYPE I" pretty quickly. However, binary transfers are inappropriate for directory listings, especially when you connect to an EBCDIC machine :-O IMO, "TYPE I" should be sent directly before trying RETR, and should be set back to "TYPE A" again when RETR failed and we are getting a LISTing instead. See RFC959. Also, the suffix ";type=[aid]" could be extended to allow for ";type=e" for forced EBCDIC transfer ;-) Not that I know a client which uses it. * The code path thru the proxy_ftp_handler is rather convoluted. My rewrite funnels each return() thru a common function which cleans up, closing BUFFs or sockets where needed. The current code has MANY returns which do not clean up properly. This led to my Apache server running out of children after a while (because each child kept an open FTP connection to the ftp server). "Apachectl restart" saved the day ;-) * the so called "%2F" hack, which would allow a user of the proxy to selectively start with either her home dir (ftp://user@host/) or with the root dir of the system (by using ftp://user@host/%2f/) is implemented in squid. Wouldn't it be nice to have it in our proxy too? * Speaking of %2f: Apache's verification checks for path components are not executed for the ftp proxy, it uses its own url encoding and decoding, and many security checks are missing there. You can go get ftp://user@host/%2fetc%2fpasswd or even ftp://user@host/%2fetc%2fdefaults%2f%2e%2e%2fgroup without any complaints by the proxy. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
[Apache-1.3]: Why is ScriptLog context only "server config"?
Was there a reasoning behind the fact that the ScriptLog* directives can only be set in the global scope? I cannot, for instance, say: Alias /cgi-bin /usr/local/apache/cgi-bin Alias /cgi-dbg /usr/local/apache/cgi-bin ScriptLog /tmp/cgi-dbg.log ... to enable debugging only for certain requests, and not for the 99% others. Or think of and . Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Apache-1.3.23: [warn] module is already added, skipping
Hi everyone, Since changing to 1.3.23, I observe the following warnings in the error log: [Fri Jan 25 15:29:47 2002] [warn] module mod_dir.c is already added, skipping [Fri Jan 25 15:29:47 2002] [warn] module mod_cgi.c is already added, skipping [Fri Jan 25 15:29:47 2002] [warn] module mod_asis.c is already added, skipping In my config file, I use --httpd.conf-- ... # Read the list of loadable modules from the configuration file dso.conf Include conf/dso.conf ... --httpd.conf-- which includes an automatically generated dso.conf (by an AWK script which reorders LoadModule and AddModule so that maintenance becomes much easier -- you can easily comment or uncomment an optional module): --dso.conf-- ClearModuleList # Built-in so Module: (this module must be added first!) AddModule mod_so.c # MicrosoftFree Friday #LoadModule msff_module libexec/mod_msff.so #AddModule mod_msff.c # Dynamically loaded mmap_static Module: LoadModule mmap_static_module libexec/mod_mmap_static.so AddModule mod_mmap_static.c # Dynamically loaded vhost_alias Module: LoadModule vhost_alias_module libexec/mod_vhost_alias.so AddModule mod_vhost_alias.c ...etc... --dso.conf-- None of these directives is present more than once (only empty lines and empty comments occur more than once): --sh-- % sort dso.conf | uniq -d # --sh-- Actually, I can also inline these shuffled module lines, and I get the same warnings. IMHO the "double check" code is coded incorrectly. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
RE: client_socket bogosity...
> One Nov. 12, Ryan committed a patch creating the create_conn hook. The > idea was to move > the client_socket out of the conn_rec presumably to make available only to > the core_in and > core_out filters. However, I just found a backdoor... > > In core_create_conn() the socket is saved away thusly: > ap_set_module_config(net->c->conn_config, &core_module, csd); > > And whoever needs to access the socket does this: > apr_socket_t *csd = ap_get_module_config(f->c->conn_config, &core_module); That hack was added because the proxy does the completely wrong thing with regard to handing sockets. In order to finish the Nov. 12 patch, I need to rip a lot of logic out of the proxy and re-implement, which I haven't had time to do recently. The only other module that should use the get_module_config hack is the perchild module, which is also doing to completely wrong thing with regard to sockets, but I haven't had time to fix that one either. > So the goal of hiding the socket is completely blown. The Nov. 11 change > added a lot of > complexity to the server (hard to read/understand code) in pursuit of a > goal that is then > immediately circumvented by the ap_get|set_module_config. So we made the > server more > complex for no reason. It actually isn't blown. Try writing a module that implements a non TCP socket, and it will work as long as you don't use the proxy or the perchild module. As proof, look at the fact that the Unix MPMs have been using that mechanism to handle the pipe_of_death. This allowed me to remove the ugly hacks at the beginning of the accept loop, which checked for the POD. Also, a big portion of the Nov 12 patch was to consolidate the accept functions for Unix and BeOS, which has meant far less duplicated code in the server. > I am on the verge of vetoing the Nov. 12 patch in favor of moving the > client_socket back > into the con_rec. > > Comments? Please don't let two mis-behaved modules color your judgment on this. Both proxy and perchild must be re-written if they are going to be clean, and once that is done the stupid set_module_config can be removed. In fact, the server ran for over a day without the set_module_config, but that broke the proxy, so I added the hack to allow the proxy to continue to work, while I worked to solve the underlying problem. Unfortunately, work and some extracurricular activities have stopped me from contributing much code recently. Hopefully, I will have time to code again soon. Ryan
client_socket bogosity...
One Nov. 12, Ryan committed a patch creating the create_conn hook. The idea was to move the client_socket out of the conn_rec presumably to make available only to the core_in and core_out filters. However, I just found a backdoor... In core_create_conn() the socket is saved away thusly: ap_set_module_config(net->c->conn_config, &core_module, csd); And whoever needs to access the socket does this: apr_socket_t *csd = ap_get_module_config(f->c->conn_config, &core_module); So the goal of hiding the socket is completely blown. The Nov. 11 change added a lot of complexity to the server (hard to read/understand code) in pursuit of a goal that is then immediately circumvented by the ap_get|set_module_config. So we made the server more complex for no reason. I am on the verge of vetoing the Nov. 12 patch in favor of moving the client_socket back into the con_rec. Comments? Bill
Any way to return an error on the create_conn hook?
I have a module that implements a create_conn hook that can detect error conditions requiring the HTTP request to be failed. If I return NULL from the create_conn hook in my failure case, the default core hook gets run which is NOT what I want to happen. I'd like to be able to return something like -1 to tell the hook code that the request failed and to not attempt to run other create_conn hooks. Thoughts? Bill
Re: Apache2 mod_auth_ldap
Günter Knauf wrote: > can someone please explain how I can create apr_ldap.h on Win32 and > what additional defines are needed in the project in order to build mod_auth_ldap? I am not sure how to do this on win32, however you need to include --with-ldap to switch on LDAP support in APR-util, then you need to enable two modules: mod_ldap and mod_auth_ldap. If you only enable mod_auth_ldap it won't work. Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." smime.p7s Description: S/MIME Cryptographic Signature
