Re: [PATCH] Update: To version Apache-2.4.18 and PHP-5.6-17.

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4188 bytes --]

On Thu, 2016-03-03 at 14:47 +0100, ummeegge wrote:
> Hi Michael,
> yes sure if we go for a merge request we will split all the pieces in
> separated patches so it should be easier to overview and comment on
> them but in the moment there are configuration questions open but
> also more testings to do.

It is a good idea to do this right from the beginning. That saves a lot
of work later.

I can't and won't review these large patches because there is really no
point in it. They usually raise more questions than they should and
commenting inline is messy and leads into many separate conversations
about different issues. So: It will save us all loads of work.

> The first step in my opinion could be a kind of help to find a way
> for a proper, good operating mode with the new versions where we can
> find for the first a way for a moderate hardware consumption. The RAM
> usage seems to be currently a double of the existing apache/php
> installation which is in my opinion a no go especially for all the
> weak boards (256MB like e.g. the ALIX are a problem i think) out
> there.

I actually do not care that much about these. They are way below the
minimum hardware requirements and even further below under the
recommended hardware requirements.

We should not waste the memory, but when it is needed to run apache,
what else can we do?

> Unfortunatly the worker mpm mode has the lowest RAM consumption in my
> testings but it seems to be also the weakest in a security manner.
> Since the "worker" MPM uses threads and the question comes up if PHP
> are really thread save where i have in fact currently no deeper
> insights. The alternative might be to use prefork MPM which uses
> instead of threads processes and should therefor be more save but
> needs in my testings also more RAM. This situation is currently a
> dilemma where i´am not sure how to solve this but may also some other
> people in here have the time, knowhow and the muse to find a good
> solution with this.

I think we must stick with the old way. The web user interface will
fork any way, so the MPM approach will give us no advantage what so
ever.

Leaving things as they are should be the safest.

> Another section might be to try some more out with modsecurity (made
> a separated package) which is really in the beginning of testings and
> uses currently only default configs, so this can be seen as a
> playground for the first. There are also more possibilities with this
> versions where i made some switches in configure on but may too much
> or not the really useful ones, for this questions i hope to find some
> more testers which are interested to optimize this work so we can
> start at the end to make a working list of how we step further with
> the merge requests to deliver it step by step for a potential last
> overview.

I do not really get why mod_security is a thing. What are you going to
achieve with this in IPFire?

> 
> I wanted to deliver for the first tries my working environment which
> works well on my testing machine. In here --> http://git.ipfire.org/?
> p=people/ummeegge/ipfire-
> 2.x.git;a=commit;h=47e7534ec924da960610838b6d40549f50c94f56 all
> changes can be overviewed and be used.
> 
> Might be great if there comes some response. I´am on the way in the
> next 1-2 weeks so please be patient for response.
> 
> Greetings,
> 
> Erik

Best,
-Michael

> 
> 
> Am 03.03.2016 um 00:52 schrieb Michael Tremer <michael.tremer(a)ipfire.
> org>:
> 
> > Hi,
> > 
> > yes please break this up into individual patches that do small
> > changes
> > at a time.
> > 
> > You can also use RFC instead of PATCH in the headline so you can
> > ask
> > people to comment on the changes.
> > 
> > -Michael
> > 
> > On Mon, 2016-02-29 at 18:14 +0100, ummeegge wrote:
> > > Hi all,
> > > some files are missing and send-email won't deliver the amended
> > > version
> > > fatal: /tmp/pQNGd3EHcp/0001-Update-To-version-Apache-2.4.18-and-
> > > PHP-
> > > 5.6-17.patch: 627: patch contains a line longer than 998
> > > characters
> > > warning: no patches were sent
> > > 
> > > will push them soon again…
> > > 
> > > Sorry for that.
> > > 
> > > Greetings,
> > > 
> > > Erik
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]