Hi,

(...)

...

--- a/config/httpd/server-tuning.conf +++ b/config/httpd/server-tuning.conf @@ -17,10 +17,12 @@ MaxKeepAliveRequests 100 ?# ?KeepAliveTimeout 15 ? -MinSpareServers 1 -MaxSpareServers 10 -StartServers 2 -MaxClients 1000 +MinSpareThreads 1 +MaxSpareThreads 10 +StartServers 1 +MaxRequestWorkers 10 +MaxConnectionsPerChild 100 +ThreadsPerChild 10

What made you pick these values? StartServers used to be 2 before and is 1 now for example.

Yes, in the previous version, the server was using fork, now it is using threads, so one process (for startup) should be enough. We now have up to 10 threads (11, if you also count the server thread itself), which results in a total maximum of 10 simultaneous connections. After 100 connections, a thread is recycled.

For the web configuration interface, this should be enough, although one could increase the values, if necessary, allowing more MaxRequestWorkers, for example.

Also, the maximum number of server processes is not restricted any more, although the strict limit on MaxRequestWorkers should limit these automatically (to 1). So, in total this should allow one apache child process that spawns up to 10 (spare) threads that may handle connections. After 100 connections, this child process is recycled (to avoid accidental memory leakage).

I also just saw that MaxSpareThreads should be set to 11 in this case (1 spare thread and up to 10 threads handling the connection), I would correct this then.

There is always some reasoning involved in choosing the right values. If you think that running own-/nextcloud or other web server intensive tasks is one of the main selling points of IPFire, increasing these values might be necessary. I was only thinking about the web configuration interface when choosing these values. Nevertheless, I also tested some addons (without any issues), but I did not perform a load simulation.

...

? ?# ?# The following directives modify normal HTTP response behavior to diff --git a/config/httpd/ssl-global.conf b/config/httpd/ssl-global.conf index 9cf4f81..a767c10 100644 --- a/config/httpd/ssl-global.conf +++ b/config/httpd/ssl-global.conf @@ -42,7 +42,7 @@ ? #???Semaphore: ? #???Configure the path to the mutual exclusion semaphore the ? #???SSL engine uses internally for inter-process synchronization.?

• SSLMutex??file:/var/log/httpd/ssl_mutex

+# SSLMutex??file:/var/log/httpd/ssl_mutex

Instead of commenting out some deprecated directives, you should just remove these lines. If we need them back, Git will remember them :)

Will do. The original idea was to ask if there was any reason for this value to be set. I don't think that setting this directive is necessary. (...)

diff --git a/src/setup/passwords.c b/src/setup/passwords.c index e7b4b52..6242577 100644 --- a/src/setup/passwords.c +++ b/src/setup/passwords.c @@ -56,7 +56,7 @@ int handleadminpassword(void) ? return 0; ? ? snprintf(commandstring, STRING_SIZE,

• "/usr/sbin/htpasswd -c -m -b " CONFIG_ROOT "/auth/users admin
  

'%s'", password);

• "/usr/bin/htpasswd -c -B -C 7 -b " CONFIG_ROOT "/auth/users
  

admin '%s'", password); ? sprintf(message, _("Setting %s 'admin' user password..."), NAME); ? if (runhiddencommandwithstatus(commandstring, _("Setting password"), message, NULL)) { ? sprintf(message, _("Problem setting %s 'admin' user password."), NAME);

This would make it impossible to restore backups to an older version of IPFire. However, for the security, I would certainly vote for making this change any way.

Patch looks good so far. Did you test this with the current version of PHP that is currently packaged? This probably needs an update as well soon, but first I would just like to stick to Apache and do one step after the other.

I will rebase and re-run a test with the current next version.

Anything else you might expect to break or cause complications?

Addon packages need to make sure they adapt their configuration. I think I found all apache configuration files in the next branch, but if there are external addon-repositories, they might need to be adapted as well. Apache will not start, if the directives are not updated. I intentionally did not enable mod_access_compat, because the migration is not complicated and the new directives are (usually) a lot easier to use and understand. Also, this would allow to mix old and new directives... Note that some files changed their directory, so htpasswd now resides in /usr/bin instead of /usr/sbin. If there are more hardcoded system calls like in passwords.c, they need to be adapted.

I snipped the original text to make it easier to answer.

Best regards, Wolfgang