Re: [VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Mario Brandt 
Hi Jeff,
at least I can say from another build that I have made that r1500307
does not have that issue on my box Debian Box. There are the number of
processes that I see in htop and on the server status page the same.
So the issue might happen in a later revision.

Hope that helps. (May some other can try r1500307 on Windows, too).

On 29 September 2013 23:14, Jeff Trawick  wrote:
> On Sun, Sep 29, 2013 at 4:04 PM, Steffen  wrote:
>>
>>
>> Becoming dramatic here, already running over 30 processes. Running out of
>> memory this way.
>>
>>
>> All time high here is 5 processes, and while writing this mail it is
>> already 34 and all 34 have an entry in the mod_status page.
>>
>> Also looks like it is not stopping/killing processes any more, have
>> entries with 1784 seconds idle (FcgidIdleTimeout is default, 300)
>>
>> Going back to 2.3.7 at AL.
>>
>>
>> On Sunday 29/09/2013 at 21:15, Steffen  wrote:
>>
>>>
>>> Observe a different behavior compared to 2.3.7
>>>
>>>
>>> - It spawns a lot more mod_fcgid processes, looks like vhost is in charge
>>> (mod_fcgid only global defined here)
>>>
>>> - I see in Windows taskmanager and  in mod_status 5 processes and the
>>> error log says that the are 3 started, a mismatch.
>>>
>>> - Also different in mod_status page, see more then one entry for Process:
>>> php-cgi.exe
>>>
>>> With 2.3.8 splitted now :
>>>
>>> Total FastCGI processes: 5
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
>>> PidActiveIdleAccessesState
>>> 46204874317Ready
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
>>> PidActiveIdleAccessesState
>>> 38405151095Ready
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
>>> PidActiveIdleAccessesState
>>> 65525574566Ready
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
>>> PidActiveIdleAccessesState
>>> 320419627187Ready
>>> 5036 2143 17192Ready
>>>
>>>
>>> With 2.3.7 was only one entry, like:
>>>
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
>>> PidActiveIdleAccessesState
>>> 320419627187Ready
>>> 5036 2143 17192Ready
>>> ...
>>>
>>> Not really trust 2.3.8 (yet), give me a few days to observe more.
>>>
>
> Thanks, Steffen.  I'll try to reproduce soon and see which commit changed
> that.  (Maybe 1377398?)
>
>
>>>
>>>
>>>
>>>
>>> On Sunday 29/09/2013 at 20:01, Jeff Trawick  wrote:



 Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

 Shortcut to changes:
 http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID


 +/-1
 [  ] Release mod_fcgid 2.3.8 as GA

 I'll hold the vote open for 72 hours unless something out of the
 ordinary occurs.

 Thanks in advance for testing!
 --
 Born in Roswell... married an alien...
 http://emptyhammock.com/
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Jeff Trawick 
On Sun, Sep 29, 2013 at 5:14 PM, Jeff Trawick  wrote:

> On Sun, Sep 29, 2013 at 4:04 PM, Steffen  wrote:
>
>>
>> Becoming dramatic here, already running over 30 processes. Running out of
>> memory this way.
>>
>>
>> All time high here is 5 processes, and while writing this mail it is
>> already 34 and all 34 have an entry in the mod_status page.
>>
>> Also looks like it is not stopping/killing processes any more, have
>> entries with 1784 seconds idle (FcgidIdleTimeout is default, 300)
>>
>> Going back to 2.3.7 at AL.
>>
>>
>> On Sunday 29/09/2013 at 21:15, Steffen  wrote:
>>
>>
>>> Observe a different behavior compared to 2.3.7
>>>
>>>
>>> - It spawns a lot more mod_fcgid processes, looks like vhost is in
>>> charge (mod_fcgid only global defined here)
>>>
>>> - I see in Windows taskmanager and  in mod_status 5 processes and the
>>> error log says that the are 3 started, a mismatch.
>>>
>>> - Also different in mod_status page, see more then one entry for
>>> Process: php-cgi.exe
>>>
>>> With 2.3.8 splitted now :
>>>
>>> Total FastCGI processes: 5
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>>> PidActiveIdleAccessesState
>>> 46204874317Ready
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>>> PidActiveIdleAccessesState
>>> 38405151095Ready
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>>> PidActiveIdleAccessesState
>>> 65525574566Ready
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>>> PidActiveIdleAccessesState
>>> 320419627187Ready
>>> 5036 2143 17192Ready
>>>
>>>
>>> With 2.3.7 was only one entry, like:
>>>
>>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>>> PidActiveIdleAccessesState
>>> 320419627187Ready
>>> 5036 2143 17192Ready
>>> ...
>>>
>>> Not really trust 2.3.8 (yet), give me a few days to observe more.
>>>
>>>
> Thanks, Steffen.  I'll try to reproduce soon and see which commit changed
> that.  (Maybe 1377398?)
>
>
So far I've only set up a simple test...  Simple perl FastCGI script, ab -n
20 -c 20, default main vhost configuration, this for the vhost:


FCGIDCmdOptions /home/trawick/myhg/apache/fcgid/apps/altinfo.pl \
InitialEnv VHOST=any \
InitialEnv PERL5LIB=/home/trawick/perl5/lib/perl5


2.3.7 grows up to about 12 (vs. max 20 concurrent clients).
2.3.8 grows up to about 20.

I got both the fastest and slowest times for 200,000 requests using 2.3.8.
 Generally I suspect 2.3.7 is slightly faster, but I don't have a good
overall summary.

If you're using FcgidCmdOptions, I'd recommend using the MaxProcesses
parameter to something that your system can handle.  Otherwise, see
FcgidMaxProcesses and FcgidMaxProcessesPerClass.  Regardless of 2.3.7 or
2.3.8.

Still, for this simple scenario + configuration, 2.3.7 would have been
better (generally not worse performance, uses 40% fewer processes).
 Different scenarios would have different results, but I think that the
common, fat PHP processes would have bigger problems with 2.3.8 if there is
no reasonable configured limit on the max to spawn.

Does anyone else have time to play?



>
>>
>>>
>>>
>>> On Sunday 29/09/2013 at 20:01, Jeff Trawick  wrote:
>>>


 Tarballs/zips are at 
 http://httpd.apache.org/dev/**dist/mod_fcgid/

 Shortcut to changes: http://httpd.apache.org/dev/**
 dist/mod_fcgid/CHANGES-FCGID


 +/-1
 [  ] Release mod_fcgid 2.3.8 as GA

 I'll hold the vote open for 72 hours unless something out of the
  ordinary occurs.

 Thanks in advance for testing!
 --
 Born in Roswell... married an alien...
 http://emptyhammock.com/

>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Jeff Trawick 
On Sun, Sep 29, 2013 at 4:04 PM, Steffen  wrote:

>
> Becoming dramatic here, already running over 30 processes. Running out of
> memory this way.
>
>
> All time high here is 5 processes, and while writing this mail it is
> already 34 and all 34 have an entry in the mod_status page.
>
> Also looks like it is not stopping/killing processes any more, have
> entries with 1784 seconds idle (FcgidIdleTimeout is default, 300)
>
> Going back to 2.3.7 at AL.
>
>
> On Sunday 29/09/2013 at 21:15, Steffen  wrote:
>
>
>> Observe a different behavior compared to 2.3.7
>>
>>
>> - It spawns a lot more mod_fcgid processes, looks like vhost is in charge
>> (mod_fcgid only global defined here)
>>
>> - I see in Windows taskmanager and  in mod_status 5 processes and the
>> error log says that the are 3 started, a mismatch.
>>
>> - Also different in mod_status page, see more then one entry for Process:
>> php-cgi.exe
>>
>> With 2.3.8 splitted now :
>>
>> Total FastCGI processes: 5
>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>> PidActiveIdleAccessesState
>> 46204874317Ready
>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>> PidActiveIdleAccessesState
>> 38405151095Ready
>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>> PidActiveIdleAccessesState
>> 65525574566Ready
>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>> PidActiveIdleAccessesState
>> 320419627187Ready
>> 5036 2143 17192Ready
>>
>>
>> With 2.3.7 was only one entry, like:
>>
>> Process: php-cgi.exe  (d:/servers/apache/php/php-**cgi.exe)
>> PidActiveIdleAccessesState
>> 320419627187Ready
>> 5036 2143 17192Ready
>> ...
>>
>> Not really trust 2.3.8 (yet), give me a few days to observe more.
>>
>>
Thanks, Steffen.  I'll try to reproduce soon and see which commit changed
that.  (Maybe 1377398?)



>
>>
>>
>> On Sunday 29/09/2013 at 20:01, Jeff Trawick  wrote:
>>
>>>
>>>
>>> Tarballs/zips are at 
>>> http://httpd.apache.org/dev/**dist/mod_fcgid/
>>>
>>> Shortcut to changes: http://httpd.apache.org/dev/**
>>> dist/mod_fcgid/CHANGES-FCGID
>>>
>>>
>>> +/-1
>>> [  ] Release mod_fcgid 2.3.8 as GA
>>>
>>> I'll hold the vote open for 72 hours unless something out of the
>>>  ordinary occurs.
>>>
>>> Thanks in advance for testing!
>>> --
>>> Born in Roswell... married an alien...
>>> http://emptyhammock.com/
>>>
>>
>>
>>
>>
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Steffen 


Becoming dramatic here, already running over 30 processes. Running out 
of memory this way.



All time high here is 5 processes, and while writing this mail it is 
already 34 and all 34 have an entry in the mod_status page.


Also looks like it is not stopping/killing processes any more, have 
entries with 1784 seconds idle (FcgidIdleTimeout is default, 300)


Going back to 2.3.7 at AL.


On Sunday 29/09/2013 at 21:15, Steffen  wrote:


Observe a different behavior compared to 2.3.7


- It spawns a lot more mod_fcgid processes, looks like vhost is in 
charge (mod_fcgid only global defined here)


- I see in Windows taskmanager and  in mod_status 5 processes and the 
error log says that the are 3 started, a mismatch.


- Also different in mod_status page, see more then one entry for 
Process: php-cgi.exe


With 2.3.8 splitted now :

Total FastCGI processes: 5
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
46204874317Ready
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
38405151095Ready
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
65525574566Ready
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
320419627187Ready
5036214317192Ready


With 2.3.7 was only one entry, like:

Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
320419627187Ready
5036214317192Ready
...

Not really trust 2.3.8 (yet), give me a few days to observe more.




On Sunday 29/09/2013 at 20:01, Jeff Trawick  wrote:



Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes: 
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID



+/-1
[  ] Release mod_fcgid 2.3.8 as GA

I'll hold the vote open for 72 hours unless something out of the  
ordinary occurs.


Thanks in advance for testing!
--
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Steffen 


Observe a different behavior compared to 2.3.7


- It spawns a lot more mod_fcgid processes, looks like vhost is in 
charge (mod_fcgid only global defined here)


- I see in Windows taskmanager and  in mod_status 5 processes and the 
error log says that the are 3 started, a mismatch.


- Also different in mod_status page, see more then one entry for 
Process: php-cgi.exe


With 2.3.8 splitted now :

Total FastCGI processes: 5
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
46204874317Ready
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
38405151095Ready
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
65525574566Ready
Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
320419627187Ready
5036214317192Ready


With 2.3.7 was only one entry, like:

Process: php-cgi.exe  (d:/servers/apache/php/php-cgi.exe)
PidActiveIdleAccessesState
320419627187Ready
5036214317192Ready
...

Not really trust 2.3.8 (yet), give me a few days to observe more.




On Sunday 29/09/2013 at 20:01, Jeff Trawick  wrote:


Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes: 
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID



+/-1
[  ] Release mod_fcgid 2.3.8 as GA

I'll hold the vote open for 72 hours unless something out of the 
ordinary occurs.


Thanks in advance for testing!
--
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Mario Brandt 
On 29 September 2013 20:00, Jeff Trawick  wrote:
> Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/
>
> Shortcut to changes:
> http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID
>
> +/-1
[ +1 ] Release mod_fcgid 2.3.8 as GA

tested on Debian 7 with PHP 5.4 (distro) and 5.5 (dotdeb)

>
> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>
> Thanks in advance for testing!
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/

[VOTE] Release mod_fcgid 2.3.8

2013-09-29 Thread Jeff Trawick 
Tarballs/zips are at http://httpd.apache.org/dev/dist/mod_fcgid/

Shortcut to changes:
http://httpd.apache.org/dev/dist/mod_fcgid/CHANGES-FCGID

+/-1
[  ] Release mod_fcgid 2.3.8 as GA

I'll hold the vote open for 72 hours unless something out of the ordinary
occurs.

Thanks in advance for testing!

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Streamlining/improving ephemeral key handling in mod_ssl?

2013-09-29 Thread Hanno Böck 
On Wed, 25 Sep 2013 07:35:10 +0200
Kaspar Brand  wrote:

> Thanks Joe and Rüdiger for your feedback. I'm going to finish and
> commit part1 of the patch next (which seems uncontroversial), and
> wait a few more days for opinions re: OpenSSL 0.9.8a, see also the
> separate thread.

Thanks a lot that there's finally some movement here.

What needs to happen so this can be backported to 2.4? Regarding the
discussion on ietf-tls happening right now, it'd be a good signal if
apache would support larger DH parameters soon.

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

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


signature.asc
Description: PGP signature

Re: [PATCH 49220] mod_fcgid - restrict arbitrary command execution from .htaccess files

2013-09-29 Thread Jeff Trawick 
On Fri, Sep 27, 2013 at 1:56 PM, Benjamin Coddington wrote:

> On Sep 27, 2013, at 1:50 PM, Benjamin Coddington  wrote:
>
> > since I'll now need to generate a large number of
> > AllowOverrideList configurations in order to implement this across our
> > hosting - which requires I walk our modules to find all the directives in
> > FileInfo and explicitly allow them to disable these mod_fcgid directives.
>
> Or... just use this:
>
> httpd -L | grep -B3 FileInfo | grep -B2 .htaccess | egrep '^\w'
>
> Ben
>

As you have a solution with httpd 2.4.x, I won't think any more about this
for fcgid 2.3.next.  (And as time goes on it is less useful to others
anyway.)

Re: "Forbid" directive in core?

2013-09-29 Thread Stefan Fritsch 
Am Samstag, 28. September 2013, 09:19:28 schrieb Eric Covener:
> I've come back to this because I've struggled in another area with
> access_checker vs. access_checker_ex.  I really think we need basic
> access control outside of Require and Satisfy.
> 
> I have a copy of the "Forbidden" directive in mod_authz_core and I
> am currrently allowing ON/OFF flags.
> 
> * using a new directive means someone won't casually add "forbidden
> OFF" when they think they're turnong on more access control with
> Require
> * we can document that "forbidden OFF" is extreme from the start.
> 
> I am on the fence about having an argument at all.  My fear is that
> it will evolve into a misguided FAQ of 'try forbidden OFF if you
> get a 403' then we're right back to
> 
> 
> Forbidden
> 
> 
> ...
> 
> 
> ...
> Require ldap-group cn=foo
> Forbidden OFF
> 
> 
> Any thoughts on keeping the flag?

I am not sure this is enough. I think it can happen that one wants to 
override one specific Forbidden but not any others. Consider the 
following config:


 Forbidden



 Forbidden off



 Forbidden



 Forbidden



If I now want to allow PUT/DELETE for a specific directory without 
allowing access to .htaccess files, that would be very difficult.

One idea similar but not quite like Tim's suggestion would be to add a 
tag parameter to Forbidden, and to require the exact same tag 
parameter for a "forbidden off" to be effective. 


 Forbidden tag=paths



 Forbidden tag=paths off



 Forbidden tag=htaccess



 Forbidden tag=methods



Then a 


 Forbidden tag=methods off


would do the right thing.

If we don't offer a wildcard 'Forbidden tag=* off', then the 
possiblity for misguided FAQs to cause security issues would be 
limited. Not specifying a tag would imply tag=default and not tag=*.

Of course, instead of doing this for a new Forbidden tag, we could do 
this for all authz, too.


  
Require all denied
  


Authz directives would then only be merged within their own tag.

Maybe requiring to define the possible tags before use would be a good 
idea to catch typos. And allowing to define which of these may be used 
in .htaccess would be good, too. Probably some other name than 'tag' 
would be better. Scope? Tier?

I haven't though about how easy this would be to implement in a 
performant way, though. And it would increase the complexity of the 
configurations quite a bit. But it would make it easier to avoid 
accidental security problems.

Re: [PATCH 55593] Add "SSLServerInfoFile" directive

2013-09-29 Thread Kaspar Brand 
On 28.09.2013 18:34, Dr Stephen Henson wrote:
> How about something like:
> 
> int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
> 
> which can return things like...
> 
> SSL_CONF_TYPE_INVALID:unrecognised name.
> SSL_CONF_TYPE_FILE:   file name.
> SSL_CONF_TYPE_DIR:directory name.
> ... others ...
> SSL_CONF_TYPE_STR:string with no special meaning.

Sounds good, yes. This would also allow us to do a little more sanity
checking in ssl_engine_config.c:ssl_cmd_SSLOpenSSLConfCmd() - e.g. for
invalid command names (which are currently not rejected with "httpd
-t"... only when httpd is started).

Kaspar