From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Apolinarski To: development@lists.ipfire.org Subject: RE: [PATCH 2/2] Update to apache 2.4.27 Date: Fri, 18 Aug 2017 19:47:47 +0200 Message-ID: <000001d3184a$1aab0b20$50012160$@apolinarski.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0785756381981284035==" List-Id: --===============0785756381981284035== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, >=20 > this patch looks quite good I think. A few small comments below... >=20 > On Tue, 2017-08-15 at 22:43 +0200, Wolfgang Apolinarski wrote: > > - Updated to apache 2.4 > > - Updated the htpasswd generation to use the more secure bcrypt > > algorithm > > --- > > config/httpd/httpd.conf | 4 +- > > config/httpd/loadmodule.conf | 10 +- > > config/httpd/server-tuning.conf | 10 +- > > config/httpd/ssl-global.conf | 5 - > > config/httpd/vhosts.d/ipfire-interface-ssl.conf | 20 +- > > config/httpd/vhosts.d/ipfire-interface.conf | 18 +- > > config/httpd/vhosts.d/nagios.conf | 14 +- > > config/httpd/vhosts.d/openmailadmin.conf | 3 +- > > config/icinga/icinga.conf | 6 - > > config/nagiosql/nagios.conf | 17 +- > > config/owncloud/owncloud.conf | 3 +- > > config/php/php.ini | 2 +- > > config/phpSANE/phpSANE.conf | 3 +- > > config/rootfiles/common/apache2 | 604 > > +++++++++++++++++------- > > config/rootfiles/common/php | 7 +- > > lfs/apache2 | 28 +- > > src/setup/passwords.c | 2 +- > > 17 files changed, 498 insertions(+), 258 deletions(-) > > > > diff --git a/config/httpd/httpd.conf b/config/httpd/httpd.conf > > index 9c1fb2b10..14dcc735c 100644 > > --- a/config/httpd/httpd.conf > > +++ b/config/httpd/httpd.conf > > @@ -65,7 +65,6 @@ Include /etc/httpd/conf/global.conf > > > > # associate MIME types with filename extensions > > TypesConfig /etc/mime.types > > -DefaultType text/plain > > > > # global (server-wide) SSL configuration, that is not specific to > > # any virtual host > > @@ -80,8 +79,7 @@ Include /etc/httpd/conf/ssl-global.conf > > AccessFileName .htaccess > > # and never show them > > > > - Order allow,deny > > - Deny from all > > + Require all denied > > > > > > # List of resources to look for when the client requests a directory > > diff --git a/config/httpd/loadmodule.conf > > b/config/httpd/loadmodule.conf > > index e30f79b28..249221e8c 100644 > > --- a/config/httpd/loadmodule.conf > > +++ b/config/httpd/loadmodule.conf > > @@ -1,8 +1,11 @@ > > LoadModule authn_file_module /usr/lib/apache/mod_authn_file.so > > +LoadModule unixd_module /usr/lib/apache/mod_unixd.so > > #LoadModule authn_dbm_module /usr/lib/apache/mod_authn_dbm.so > > #LoadModule authn_anon_module /usr/lib/apache/mod_authn_anon.so > > #LoadModule authn_dbd_module /usr/lib/apache/mod_authn_dbd.so > > #LoadModule authn_default_module > > /usr/lib/apache/mod_authn_default.so > > +LoadModule authn_core_module /usr/lib/apache/mod_authn_core.so > > +LoadModule authz_core_module /usr/lib/apache/mod_authz_core.so > > LoadModule authz_host_module /usr/lib/apache/mod_authz_host.so > > #LoadModule authz_groupfile_module > > /usr/lib/apache/mod_authz_groupfile.so > > LoadModule authz_user_module /usr/lib/apache/mod_authz_user.so > > @@ -10,7 +13,7 @@ LoadModule authz_user_module > > /usr/lib/apache/mod_authz_user.so > > #LoadModule authz_owner_module /usr/lib/apache/mod_authz_owner.so > > #LoadModule authz_default_module > > /usr/lib/apache/mod_authz_default.so > > LoadModule auth_basic_module /usr/lib/apache/mod_auth_basic.so > > -LoadModule auth_digest_module /usr/lib/apache/mod_auth_digest.so > > +#LoadModule auth_digest_module /usr/lib/apache/mod_auth_digest.so >=20 > Any reason this is suddenly deactivated? I know we don't really use > this anywhere but just asking... Yes, I wrote a mail on the 18th of May that explained the modules and the cha= nges (ok, that is long ago). Since you suggested that fewer modules result in a smaller attack surface, I = disabled this module. In general, auth digest is not secure and not even more secure than basic aut= h: To cite the apache documentation: "Another problem is that the storage of the= passwords on the server is insecure. The contents of a stolen htdigest file = can be used directly for digest authentication." Since almost no one is using auth digest and it gives no security advantage, = I thought that disabling the module makes sense. >=20 > > #LoadModule dbd_module /usr/lib/apache/mod_dbd.so > > #LoadModule dumpio_module /usr/lib/apache/mod_dumpio.so > > #LoadModule ext_filter_module /usr/lib/apache/mod_ext_filter.so > > @@ -33,10 +36,10 @@ LoadModule setenvif_module > > /usr/lib/apache/mod_setenvif.so > > LoadModule mime_module /usr/lib/apache/mod_mime.so > > #LoadModule dav_module /usr/lib/apache/mod_dav.so > > #LoadModule status_module /usr/lib/apache/mod_status.so > > -LoadModule autoindex_module /usr/lib/apache/mod_autoindex.so > > +#LoadModule autoindex_module /usr/lib/apache/mod_autoindex.so >=20 > Why is the autoindex module deactivated? I deactivated all modules that are currently not in use. Actually, the autoin= dex may lead to potential privacy issues, especially since the web server may= be used by several extensions. Although the web server should only be reacha= ble from the inner network, a user could change that configuration. If autoin= dexing is necessary, the module can be activated quite easily manually. Of course, I can activate it, if you think that this should be the default. >=20 > > #LoadModule asis_module /usr/lib/apache/mod_asis.so > > #LoadModule info_module /usr/lib/apache/mod_info.so > > -LoadModule cgi_module /usr/lib/apache/mod_cgi.so > > +LoadModule cgid_module /usr/lib/apache/mod_cgid.so > > #LoadModule dav_fs_module /usr/lib/apache/mod_dav_fs.so > > #LoadModule vhost_alias_module /usr/lib/apache/mod_vhost_alias.so > > #LoadModule negotiation_module /usr/lib/apache/mod_negotiation.so > > @@ -47,5 +50,6 @@ LoadModule dir_module /usr/lib/apache/mod_dir.so > > #LoadModule userdir_module /usr/lib/apache/mod_userdir.so > > LoadModule alias_module /usr/lib/apache/mod_alias.so > > LoadModule rewrite_module /usr/lib/apache/mod_rewrite.so > > +LoadModule socache_shmcb_module /usr/lib/apache/mod_socache_shmcb.so >=20 > Do we need this module? Yes, it is used by the SSLSessionCache. >=20 > > LoadModule ssl_module /usr/lib/apache/mod_ssl.so > > LoadModule php5_module /usr/lib/apache/libphp5.so > > diff --git a/config/httpd/server-tuning.conf b/config/httpd/server- > > tuning.conf > > index 90410186d..5edfb990e 100644 > > --- 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 256 > > +MinSpareThreads 1 > > +MaxSpareThreads 11 > > +StartServers 1 > > +MaxRequestWorkers 10 > > +MaxConnectionsPerChild 100 > > +ThreadsPerChild 10 >=20 > For what reason did you change the number of started servers and > clients. We recently adjusted this a little since there were problems > with update accelerator in large networks. Ok, I will try to come up with a configuration that is quite similar to the c= urrent configuration, then. During my tests, the web server was always very r= esponsive, even with extensions like owncloud, but there are plenty of config= urations and systems that I cannot test, so sticking as close as possible to = the existing configuration might be a good idea. (...) > > @@ -1146,13 +1452,21 @@ etc/httpd/conf/vhosts.d/ipfire-interface.conf > > #srv/web/ipfire/manual/vhosts/name-based.html.ja.utf8 > > #srv/web/ipfire/manual/vhosts/name-based.html.ko.euc-kr > > #srv/web/ipfire/manual/vhosts/name-based.html.tr.utf8 > > -#usr/bin/apr-1-config > > -#usr/bin/apu-1-config > > +#usr/bin/ab > > +#usr/bin/apxs > > +#usr/bin/dbmmanage > > +#usr/bin/htdbm > > +#usr/bin/htdigest > > +usr/bin/htpasswd > > +#usr/bin/httxt2dbm > > +#usr/bin/logresolve > > #usr/include/apache (...) > > -#usr/lib/libaprutil-1.so.0.5.3 > > -#usr/lib/pkgconfig/apr-1.pc > > -#usr/lib/pkgconfig/apr-util-1.pc > > -#usr/sbin/ab > > +usr/lib/apache/mod_watchdog.so > > +usr/lib/apache/mod_xml2enc.so > > usr/sbin/apachectl > > -#usr/sbin/apxs > > #usr/sbin/checkgid > > -#usr/sbin/dbmmanage > > #usr/sbin/envvars > > #usr/sbin/envvars-std > > +usr/sbin/fcgistarter > > #usr/sbin/htcacheclean > > -#usr/sbin/htdbm > > -#usr/sbin/htdigest > > -usr/sbin/htpasswd > > usr/sbin/httpd > > -#usr/sbin/httxt2dbm > > -#usr/sbin/logresolve > > #usr/sbin/rotatelogs >=20 > All the commands that have been moved from /usr/sbin to /usr/bin must > be deleted manually when installing the core update. This would be htpasswd only, right? Can I do anything that eases the process? > > +#usr/share/man/man1/ab.1 > > > > install : $(TARGET) > > > > @@ -75,7 +78,7 @@ $(subst %,%_MD5,$(objects)) : > > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > > @$(PREBUILD) > > @rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar jxf > > $(DIR_DL)/$(DL_FILE) > > - cd $(DIR_APP) && patch -Np1 -i $(DIR_DL)/httpd-2.2.2-config- > > 1.patch > > + cd $(DIR_APP) && patch -Np0 -i $(DIR_DL)/PR61382-Fix.patch > > > > ### Add IPFire's layout, too > > echo "# IPFire layout" >> $(DIR_APP)/config.layout > > @@ -103,14 +106,15 @@ $(TARGET) : $(patsubst > > %,$(DIR_DL)/%,$(objects)) > > echo "" >> $(DIR_APP)/config.layout > > > > cd $(DIR_APP) && ./configure --enable-layout=3DIPFire \ > > - --enable-ssl --enable-mods- > > shared=3Dall --enable-proxy > > + --enable-ssl --enable-mods- > > shared=3Dall --enable-proxy --with-mpm=3Devent >=20 > And lastly the big question: Why MPM? What happened to prefork? > Advantages/disadvantages? Prefork is quite memory intensive. Event is stable and chosen as default on m= any distributions. The apache documentation states: "In the case of Unix, the decision as to which MPM is installed is based on t= wo questions: 1. Does the system support threads? 2. Does the system support thread-safe polling (Specifically, the kqueue and = epoll functions)? If the answer to both questions is 'yes', the default MPM is event. If The answer to #1 is 'yes', but the answer to #2 is 'no', the default will = be worker. If the answer to both questions is 'no', then the default MPM will be prefork. In practical terms, this means that the default will almost always be event, = as all modern operating systems support these two features." Since we support the features and a lower memory footprint is in our interest= , I would suggest that event MPM is the right choice here. There are possible disadvantages that non-thread-safe modules could break. To= the best of my knowledge, we do not use these kind of modules and they are a= ctually quite old and usually unsupported. I still remember that apache was the common example for explaining how forkin= g network applications work. Eventually, multi-threading made it's way... (al= though preforking is still supported, of course!) (...) Best regards, Wolfgang --===============0785756381981284035==--