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@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