Re: [users@httpd] Enabling ECDHE ciphers

2014-04-17 Thread Brett @Google
*16-November-2013 Changes with Apache 2.2.26 (legacy)*

ASF changes:

  *) mod_ssl: enable support for ECC keys and ECDH ciphers.  Tested against
 OpenSSL 1.0.0b3.  [Vipul Gupta, Sander Temme, Stefan Fritsch]

So you need something at least 2.2.26 (the ECDH changes were
backported from 2.4)

We run 2.2.27 with 1.0.1g and it tests as an A on Qualsys (side effect
is you get Perfect Forward Security, except for some older IE
versions).

Cheers
Brett



On Fri, Apr 18, 2014 at 10:56 AM, Igor Cicimov  wrote:

>
> On 18/04/2014 2:30 AM, "Hanno Böck"  wrote:
> >
> > On Thu, 17 Apr 2014 12:27:37 -0400
> > Christopher Schultz  wrote:
> >
> > > I'm trying to enable (and prefer!) ECDHE ciphers for clients that can
> > > support them. I've done the obvious:
> > [...]
> > > I'm running httpd 2.2.23
> >
> > That's your problem. Get rid of that old cruft. You'll need apache 2.4
> > (for that and for many other improvements regarding ssl encryption).
> >
> No you don't i have 2.2 with latest openssl-1.0.1g on all my servers and
> TLSv1.2 and ECDHE ciphers are supported.
>
> > --
> > Hanno Böck
> > http://hboeck.de/
> >
> > mail/jabber: ha...@hboeck.de
> > GPG: BBB51E42
>



-- 
Whenever you find yourself on the side of the majority, it is time to pause
and reflect.

- Mark Twain


Re: [users@httpd] Enabling ECDHE ciphers

2014-04-17 Thread Igor Cicimov
On Fri, Apr 18, 2014 at 2:27 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

>
> I'm running httpd 2.2.23 on Amazon Linux. I read in the comments for
> mos_ssl that httpd 2.2.24 is required for "TLSv1.2" to be specified
> directly. Is that accurate? I can see in my Qualys test that TLS 1.2 can
> be used by some of the "simulated clients", so I suspect that it is in
> fact available -- perhaps just not preferred?
>
> As far as I know it is the difference in the mod_ssl support.


Re: [users@httpd] Enabling ECDHE ciphers

2014-04-17 Thread Igor Cicimov
On 18/04/2014 2:30 AM, "Hanno Böck"  wrote:
>
> On Thu, 17 Apr 2014 12:27:37 -0400
> Christopher Schultz  wrote:
>
> > I'm trying to enable (and prefer!) ECDHE ciphers for clients that can
> > support them. I've done the obvious:
> [...]
> > I'm running httpd 2.2.23
>
> That's your problem. Get rid of that old cruft. You'll need apache 2.4
> (for that and for many other improvements regarding ssl encryption).
>
No you don't i have 2.2 with latest openssl-1.0.1g on all my servers and
TLSv1.2 and ECDHE ciphers are supported.

> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42


Re: [users@httpd] Re: ProxyPassMatch with Unix sockets

2014-04-17 Thread Igor Cicimov
On 18/04/2014 10:43 AM, "Igor Cicimov"  wrote:
>
>
> On 18/04/2014 8:25 AM, "Marc Aymerich"  wrote:
> >
> > On Thu, Apr 17, 2014 at 11:18 PM, Marc Aymerich 
wrote:
> > > On Wed, Apr 16, 2014 at 11:17 PM, Marc Aymerich 
wrote:
> > >> Hi,
> > >> I have a PHP-FPM web application that I want it to be accessed under
> > >> "/alias/" path. I'm trying to configure ProxyPassMatch with Unix
> > >> sockets but it doesn't work because it passes "/alias/" to the web
> > >> app, but this path doesn't exist :(
> > >>
> > >> What I have so far is this:
> > >>
> > >> ProxyPassMatch ^/alias/(.*\.php(/.*)?)$ \
> > >> unix:/var/run/user-fpm.sock|fcgi://localhost/home/user/webapps/app1/
> > >
> > >
> > > I think I got something :)
> > >
> > > if you guys like to comment on the following solution it would be
> > > great! (I'm kind of newbie)
> > >
> > > # Rewrite the URL before proxying
> > > RewriteRule ^/alias(.*\.php)$ $1 [L,PT]
> > >
> > > ProxyPassMatch ^/?(.*\.php)$
> > > unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/
> > >
> > > # Create an alias for app1 static content
> > > Alias /alias /home/user/webapps/app1/
> >
> >
> > Well, actually this doesn't solve my original problem which is having
> > two different php-fpm apps under the same VirtualHost.
> >
> > Based on the previous directives I kind of expected something like the
> > following to work:
> >
> > 
> > RewriteRule $1 [L,PT]
> > ProxyPassMatch
> > unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/
> > 
> >
> > 
> > RewriteRule $1 [L,PT]
> > ProxyPassMatch
> > unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app2/
> > 
> >
> >
> > But it doesn't, the RewriteRule seems to be totally ignored inside a
> > LocationMatch no matter what I put there.
> >
> Did you read
> http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch
>
And
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriterule
Pay attention to the Context which explains where the directive should be
used.

> > Any idea on how to have several fgci apps connected by sockets under
> > the same VirtualHost using different paths?
> >
> >
> > >
> > > --
> > > Marc
> >
> >
> >
> > --
> > Marc
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> > For additional commands, e-mail: users-h...@httpd.apache.org
> >


Re: [users@httpd] Re: ProxyPassMatch with Unix sockets

2014-04-17 Thread Igor Cicimov
On 18/04/2014 8:25 AM, "Marc Aymerich"  wrote:
>
> On Thu, Apr 17, 2014 at 11:18 PM, Marc Aymerich 
wrote:
> > On Wed, Apr 16, 2014 at 11:17 PM, Marc Aymerich 
wrote:
> >> Hi,
> >> I have a PHP-FPM web application that I want it to be accessed under
> >> "/alias/" path. I'm trying to configure ProxyPassMatch with Unix
> >> sockets but it doesn't work because it passes "/alias/" to the web
> >> app, but this path doesn't exist :(
> >>
> >> What I have so far is this:
> >>
> >> ProxyPassMatch ^/alias/(.*\.php(/.*)?)$ \
> >> unix:/var/run/user-fpm.sock|fcgi://localhost/home/user/webapps/app1/
> >
> >
> > I think I got something :)
> >
> > if you guys like to comment on the following solution it would be
> > great! (I'm kind of newbie)
> >
> > # Rewrite the URL before proxying
> > RewriteRule ^/alias(.*\.php)$ $1 [L,PT]
> >
> > ProxyPassMatch ^/?(.*\.php)$
> > unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/
> >
> > # Create an alias for app1 static content
> > Alias /alias /home/user/webapps/app1/
>
>
> Well, actually this doesn't solve my original problem which is having
> two different php-fpm apps under the same VirtualHost.
>
> Based on the previous directives I kind of expected something like the
> following to work:
>
> 
> RewriteRule $1 [L,PT]
> ProxyPassMatch
> unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/
> 
>
> 
> RewriteRule $1 [L,PT]
> ProxyPassMatch
> unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app2/
> 
>
>
> But it doesn't, the RewriteRule seems to be totally ignored inside a
> LocationMatch no matter what I put there.
>
Did you read
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassmatch

> Any idea on how to have several fgci apps connected by sockets under
> the same VirtualHost using different paths?
>
>
> >
> > --
> > Marc
>
>
>
> --
> Marc
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>


[users@httpd] New install of Apache not accepting client certs

2014-04-17 Thread D'Arcy J.M. Cain
I just upgraded my Apache from 2.4.7 to 2.4.9 and now my clients' cert
give me a "server certificate does NOT include an ID which matches the
server name" error and it serves the system cert instead which fails
because it doesn't match the domain.  Here is an example (sanitized)
entry in my httpd.conf.  Any ideas?  I am reverting to 2.4.7 in the
meantime.


ServerName wwws.example.com
DocumentRoot /u/WEB/user
ServerAdmin webmas...@vex.net
SuexecUserGroup user user
 
Include /VEX/templates/www/httpd-ssl.conf
SSLCertificateFile /VEX/certs/wwws.example.com.cert
SSLCertificateKeyFile /etc/certs/wwws.example.com.key

--

/VEX/templates/www/httpd-ssl.conf contains this:

SSLEngine on
 

SSLOptions +StdEnvVars

 
SetEnvIf User-Agent ".*MSIE.*" \
 nokeepalive ssl-unclean-shutdown \
 downgrade-1.0 force-response-1.0


-- 
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] HTTPS configuration problem.

2014-04-17 Thread Mark London

On 4/17/2014 3:46 PM, Yehuda Katz wrote:

On Thu, Apr 17, 2014 at 3:12 PM, Mark London mailto:m...@psfc.mit.edu>>wrote:

So I've been trying to find a configuration that redirects 
HTTPS://XXX.COMto HTTPS://WWW.XXX.COM.  Unfortunately,
every configuration that I've tried, doesn't work.  All of the rewrite and 
redirect rules, are applied after the
browser checks the certificate against the URL.   Thus, the warning web 
page always appears.


This is the expected behavior and other than issuing a new certificate and using another vhost (with SNI - generally 
not compatible with Windows XP and some other devices) or reissuing the same certificate with an additional name, 
there is no way around this.


Thanks, that confirms what I thought. - Mark



[users@httpd] Re: ProxyPassMatch with Unix sockets

2014-04-17 Thread Marc Aymerich
On Thu, Apr 17, 2014 at 11:18 PM, Marc Aymerich  wrote:
> On Wed, Apr 16, 2014 at 11:17 PM, Marc Aymerich  wrote:
>> Hi,
>> I have a PHP-FPM web application that I want it to be accessed under
>> "/alias/" path. I'm trying to configure ProxyPassMatch with Unix
>> sockets but it doesn't work because it passes "/alias/" to the web
>> app, but this path doesn't exist :(
>>
>> What I have so far is this:
>>
>> ProxyPassMatch ^/alias/(.*\.php(/.*)?)$ \
>> unix:/var/run/user-fpm.sock|fcgi://localhost/home/user/webapps/app1/
>
>
> I think I got something :)
>
> if you guys like to comment on the following solution it would be
> great! (I'm kind of newbie)
>
> # Rewrite the URL before proxying
> RewriteRule ^/alias(.*\.php)$ $1 [L,PT]
>
> ProxyPassMatch ^/?(.*\.php)$
> unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/
>
> # Create an alias for app1 static content
> Alias /alias /home/user/webapps/app1/


Well, actually this doesn't solve my original problem which is having
two different php-fpm apps under the same VirtualHost.

Based on the previous directives I kind of expected something like the
following to work:


RewriteRule $1 [L,PT]
ProxyPassMatch
unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/



RewriteRule $1 [L,PT]
ProxyPassMatch
unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app2/



But it doesn't, the RewriteRule seems to be totally ignored inside a
LocationMatch no matter what I put there.

Any idea on how to have several fgci apps connected by sockets under
the same VirtualHost using different paths?


>
> --
> Marc



-- 
Marc

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



[users@httpd] Re: Conditional response body modification

2014-04-17 Thread Doug Strick
I've come up with the below config using mod_ext_filter which isn't
desirable, but it's the only thing I've been able to come up with so far.
 It's not working exactly yet.  Any suggestions?


SetEnvIf HTTP_COOKIE "USER_TYPE=test" FILTER=$1


*Inside VirtualHost:*

ExtFilterDefine doug mode=output intype=text/html enableenv=FILTER \

cmd="/bin/bash /apps/httpd/scripts/replace.sh"





  SetOutputFilter doug





*replace.sh*

#!/bin/bash


/bin/sed -r 's/http\:\/\//https\:\/\//g'


On Wed, Apr 16, 2014 at 10:23 AM, Doug Strick wrote:

> Hello,
>
> I'm looking for a way to modify the data on outgoing requests
> conditionally.  I've tried using mod_substitute, but that appears to be an
> all or nothing module.  The documentation for mod_filter says it can be
> invoked on environment variables, but it's not exactly clear on the valid
> syntax for those variables.  Basically, I'm looking for a way to change all
> links from HTTP to HTTPS in my outgoing responses for users with a specific
> cookie.  Any suggestions?  Thanks
>


Re: [users@httpd] Enabling ECDHE ciphers

2014-04-17 Thread Christopher Schultz
Hanno,

On 4/17/14, 12:29 PM, Hanno Böck wrote:
> On Thu, 17 Apr 2014 12:27:37 -0400
> Christopher Schultz  wrote:
> 
>> I'm trying to enable (and prefer!) ECDHE ciphers for clients that can
>> support them. I've done the obvious:
> [...]
>> I'm running httpd 2.2.23
> 
> That's your problem. Get rid of that old cruft. You'll need apache 2.4
> (for that and for many other improvements regarding ssl encryption).

What is it about httpd 2.4 that enables a particular cipher? I figured
that if OpenSSL supported it, httpd would as well. Is there something
about ECDHE that requires more plumbing on the httpd side?

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature


[users@httpd] Re: ProxyPassMatch with Unix sockets

2014-04-17 Thread Marc Aymerich
On Wed, Apr 16, 2014 at 11:17 PM, Marc Aymerich  wrote:
> Hi,
> I have a PHP-FPM web application that I want it to be accessed under
> "/alias/" path. I'm trying to configure ProxyPassMatch with Unix
> sockets but it doesn't work because it passes "/alias/" to the web
> app, but this path doesn't exist :(
>
> What I have so far is this:
>
> ProxyPassMatch ^/alias/(.*\.php(/.*)?)$ \
> unix:/var/run/user-fpm.sock|fcgi://localhost/home/user/webapps/app1/


I think I got something :)

if you guys like to comment on the following solution it would be
great! (I'm kind of newbie)

# Rewrite the URL before proxying
RewriteRule ^/alias(.*\.php)$ $1 [L,PT]

ProxyPassMatch ^/?(.*\.php)$
unix:/var/run/user.sock|fcgi://127.0.0.1/home/user/webapps/app1/

# Create an alias for app1 static content
Alias /alias /home/user/webapps/app1/


-- 
Marc

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] HTTPS configuration problem.

2014-04-17 Thread Mark Brodis
Do the users actually connect to "https://xxx.com"; ?  Or do they go just to
"xxx.com" in their browser and then a load-balancer/SSL-accellerator
somewhere along the way bumps them to https?

If something was bumping them to https then it would be easiest to just
change that 'bumping' to go from "http://xxx.com"; to "https://www.xxx.com";,
which ofcourse any webserver could do (with a default document with a
meta-refresh), but most content-source-switches or
local-traffic-managers/loadbalancers could do right in the config (i.e.
they respond to the GET / with a HTTP 302 go-over-here, etc), i.e. actually
function as a limited in-line web-server.

Good luck...


On Thu, Apr 17, 2014 at 1:46 PM, Yehuda Katz  wrote:

> On Thu, Apr 17, 2014 at 3:12 PM, Mark London  wrote:
>
>> So I've been trying to find a configuration that redirects
>> HTTPS://XXX.COM to HTTPS://WWW.XXX.COM.  Unfortunately, every
>> configuration that I've tried, doesn't work.  All of the rewrite and
>> redirect rules, are applied after the browser checks the certificate
>> against the URL.   Thus, the warning web page always appears.
>>
>
> This is the expected behavior and other than issuing a new certificate and
> using another vhost (with SNI - generally not compatible with Windows XP
> and some other devices) or reissuing the same certificate with an
> additional name, there is no way around this.
>
> - Y
>


Re: [users@httpd] HTTPS configuration problem.

2014-04-17 Thread Yehuda Katz
On Thu, Apr 17, 2014 at 3:12 PM, Mark London  wrote:

> So I've been trying to find a configuration that redirects HTTPS://XXX.COMto
> HTTPS://WWW.XXX.COM.  Unfortunately, every configuration that I've tried,
> doesn't work.  All of the rewrite and redirect rules, are applied after the
> browser checks the certificate against the URL.   Thus, the warning web
> page always appears.
>

This is the expected behavior and other than issuing a new certificate and
using another vhost (with SNI - generally not compatible with Windows XP
and some other devices) or reissuing the same certificate with an
additional name, there is no way around this.

- Y


[users@httpd] HTTPS configuration problem.

2014-04-17 Thread Mark London
Hi - I inherited a web server from another site.   I requested a 
wildcard certificate for that server.   What I failed to realize, was 
that a wildcard certificate only covers *.XXX.COM.  It won't cover plain 
XXX.COM.   And unfortunately, people mainly connect to the site, using 
XXX.COM   Thus, people who connect to the server using HTTPS://XXX.COM, 
get a warning message, saying that the certificate is not valid.


So I've been trying to find a configuration that redirects 
HTTPS://XXX.COM to HTTPS://WWW.XXX.COM.  Unfortunately, every 
configuration that I've tried, doesn't work.  All of the rewrite and 
redirect rules, are applied after the browser checks the certificate 
against the URL.   Thus, the warning web page always appears.


Is there a configuration to do what I want?  Or will I have to request a 
certificate for XXX.COM?  (And then configure my SSL.CONF to have 2 
virtual hosts, one for WWW.XXX.COM, and one for XXX.COM).   Thanks very 
much. - Mark




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] Enabling ECDHE ciphers

2014-04-17 Thread Hanno Böck
On Thu, 17 Apr 2014 12:27:37 -0400
Christopher Schultz  wrote:

> I'm trying to enable (and prefer!) ECDHE ciphers for clients that can
> support them. I've done the obvious:
[...]
> I'm running httpd 2.2.23

That's your problem. Get rid of that old cruft. You'll need apache 2.4
(for that and for many other improvements regarding ssl encryption).

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


signature.asc
Description: PGP signature


[users@httpd] Enabling ECDHE ciphers

2014-04-17 Thread Christopher Schultz
All,

I'm trying to enable (and prefer!) ECDHE ciphers for clients that can
support them. I've done the obvious:

SSLHonorCipherOrder Yes
SSLProtocol ALL -SSLv2
SSLCipherSuite ECDHE:ECDH:..[other stuff]

I have confirmed that, when running "openssl ciphers [stuff above]" that
I get ECDHE ciphers listed at the top of the list. I'm running OpenSSL
1.0.1g-FIPS so that shouldn't be a problem.

Both my browser and Qualys's SSL tester don't seem to be able to use
those ciphers. Is it because I haven't done run "openssl ecparam"? I
haven't seen this shown as a requirement anywhere for enabling ECDHE (or
ECDH) ciphers anywhere online, though it makes sense that I'd have to do
something like that.

Or is it because I have "SSLProtocols ALL -SSLv2", which prefers SSLv3,
then TLSv1, then TLSv1.1, etc. instead of having them in the opposite
order? I tried "SSLProtocols TLSv1.2 TLSv1.1 TLSv1 SSLv3 -SSLv2" but I
get an error saying that "TLSv1.2 is unrecognized".

I'm running httpd 2.2.23 on Amazon Linux. I read in the comments for
mos_ssl that httpd 2.2.24 is required for "TLSv1.2" to be specified
directly. Is that accurate? I can see in my Qualys test that TLS 1.2 can
be used by some of the "simulated clients", so I suspect that it is in
fact available -- perhaps just not preferred?

Any help would be appreciated.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature


Re: [users@httpd] Fwd: apache hosting unknown sites !!!

2014-04-17 Thread Jim Barchuk

HiHi!


1. The requests are not available at log because I have blocked the .ru
domains at firewall level. Let me disable the firewall to generate the logs
for you

109.188.125.110 - - [17/Apr/2014:07:27:03 +0200] "GET /Uizz9n HTTP/1.1" 301
- "http://www.tv-house.ru/detail/200/5347"; "Mozilla/5.0 (Windows NT 6.3;
WOW64; Trident/7.0; ASU2JS; rv:11.0) like Gecko"
109.188.125.110 - - [17/Apr/2014:07:27:04 +0200] "GET
/index.php?id=16&no_cache=1 HTTP/1.1" 200 9009 "
http://www.tv-house.ru/detail/200/5347"; "Mozilla/5.0 (Windows NT 6.3;
WOW64; Trident/7.0; ASU2JS; rv:11.0) like Gecko"
109.191.88.164 - - [17/Apr/2014:07:27:13 +0200] "GET
/index.php?id=16&no_cache=1 HTTP/1.1" 200 9009 "-" "libtorrent/0.16.10.0"
109.188.125.110 - - [17/Apr/2014:07:27:16 +0200] "GET
/index.php?id=16&no_cache=1 HTTP/1.1" 200 9009 "
http://www.tv-house.ru/catalog/29/200/31/"; "Mozilla/5.0 (Windows NT 6.3;
WOW64; Trident/7.0; ASU2JS; rv:11.0) like Gecko"


I am *NOT* a DNS guru. I actually learned a bunch many years ago and even 
operated BIND for a while but gave up trying to -really- learn it, and 
keep up with progress. I'm happy enough if I can keep my own /etc/hosts 
and hosted DNS llined up records straight. LOL!!


I do know how to look at a few things though.

Those two IP addresses 109.188.125.110 and 109.191.88.164 appear to be in 
a simmilar '109' range, but not close enough.


Whois n for the first one says...

% Information related to '109.188.124.0 - 109.188.127.255' ...
% Abuse contact for '109.188.124.0 - 109.188.127.255' is 
'aguz...@yotateam.com'


... and the second one ...

% Information related to '109.191.0.0 - 109.191.127.255'
% Abuse contact for '109.191.0.0 - 109.191.127.255' is 'ab...@is74.ru'

...and all other information about those #s after that is different 
content and structure, implying completely different owners and even 
different DNS hosts. I -think- That -implies- that there's no -connection- 
between the -sources- of the requests, that they're coming from completely 
different ISPs. Yet, there the requests are.


BTW when I http:// those domains I get 'tv' related pages but appear to be 
compltetly different.


With that I'm bowing out because it's way over my head. I have no doubt 
tha someone with enough dig skills could pin down the exact source of the 
problem fairly straighforwardly, but it definitely ain't me.


You -could- ask your uplink to look into it. It depends on how supportive 
they are, and how interested the particular tech person you talk with is 
interested in the problem. The reason I say it that way is that it 
-doesn't- seem to be your -uplinks- misconfiguration, so 'not their 
problem.' But because it's causing unnecessary traffic on -their- lines 
they -might- be interested. Whether you can convince them to be interested 
depends on who you talk with and how you convey the problem. Some IPSs are 
-very- concerned about user (you) inconvenience, others don't give a rat's 
ass.


Have a :) day!

Jim

--
Jim Barchuk
j...@jbarchuk.com

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org