From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer <michael.tremer@ipfire.org> To: development@lists.ipfire.org Subject: Re: [PATCH 2/2] Update to apache 2.4.27 Date: Mon, 21 Aug 2017 12:30:25 +0100 Message-ID: <1503315025.2673.18.camel@ipfire.org> In-Reply-To: <000001d3184a$1aab0b20$50012160$@apolinarski.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4478579403271347079==" List-Id: <development.lists.ipfire.org> --===============4478579403271347079== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, sorry for the late reply. On Fri, 2017-08-18 at 19:47 +0200, Wolfgang Apolinarski wrote: > Hi Michael, >=20 > >=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(-) > > >=20 > > > 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 > > >=20 > > > # associate MIME types with filename extensions > > > TypesConfig /etc/mime.types > > > -DefaultType text/plain > > >=20 > > > # 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 > > > <Files ~ "^\.ht"> > > > - Order allow,deny > > > - Deny from all > > > + Require all denied > > > </Files> > > >=20 > > > # 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... >=20 > Yes, I wrote a mail on the 18th of May that explained the modules and the c= hanges (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 a= uth: > To cite the apache documentation: "Another problem is that the storage of t= he passwords on the server is insecure. The contents of a stolen htdigest fil= e can be used directly for digest authentication." >=20 > Since almost no one is using auth digest and it gives no security advantage= , I thought that disabling the module makes sense. Very good reason and explanation. I just wanted this to be documented here in case someone is wondering later. >=20 > >=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? >=20 > I deactivated all modules that are currently not in use. Actually, the auto= index may lead to potential privacy issues, especially since the web server m= ay be used by several extensions. Although the web server should only be reac= hable from the inner network, a user could change that configuration. If auto= indexing is necessary, the module can be activated quite easily manually. >=20 > Of course, I can activate it, if you think that this should be the default. No this makes sense and is fine. We don't use the listing anywhere. >=20 > >=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? >=20 > Yes, it is used by the SSLSessionCache. Okay. >=20 > >=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 > > >=20 > > > -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. >=20 > Ok, I will try to come up with a configuration that is quite similar to the= current configuration, then. During my tests, the web server was always very= responsive, even with extensions like owncloud, but there are plenty of conf= igurations and systems that I cannot test, so sticking as close as possible t= o the existing configuration might be a good idea. Yes. If apache is busy on an IPFire system it is usually with a number of files being streamed from the update accelerator cache. Therefore we should allow many connections and storage will then be the bottleneck. >=20 > (...) > > > @@ -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 >=20 > (...) > > > -#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. >=20 > This would be htpasswd only, right? Can I do anything that eases the proces= s? No not really. We just need to make sure that we delete the old files in the core update before we extract the new ones. >=20 > > > +#usr/share/man/man1/ab.1 > > >=20 > > > install : $(TARGET) > > >=20 > > > @@ -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 > > >=20 > > > ### Add IPFire's layout, too > > > echo "# IPFire layout" >> $(DIR_APP)/config.layout > > > @@ -103,14 +106,15 @@ $(TARGET) : $(patsubst > > > %,$(DIR_DL)/%,$(objects)) > > > echo "</Layout>" >> $(DIR_APP)/config.layout > > >=20 > > > 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? >=20 > Prefork is quite memory intensive. Event is stable and chosen as default on= many distributions. > The apache documentation states: > "In the case of Unix, the decision as to which MPM is installed is based on= two questions: > 1. Does the system support threads? > 2. Does the system support thread-safe polling (Specifically, the kqueue an= d 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 wil= l be worker. > If the answer to both questions is 'no', then the default MPM will be prefo= rk. > In practical terms, this means that the default will almost always be event= , as all modern operating systems support these two features." >=20 > Since we support the features and a lower memory footprint is in our intere= st, I would suggest that event MPM is the right choice here. Indeed. >=20 > 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= actually quite old and usually unsupported. We don't use any modules that are not coming with apache2. So I do not expect any problems here. >=20 > I still remember that apache was the common example for explaining how fork= ing network applications work. Eventually, multi-threading made it's way... (= although preforking is still supported, of course!) No, these are all very good reasons and you made the right decisions that I would support. The only reason against is that more changes in one feature will potentially raise more issues and prefork has been working well on IPFire for years. But with apache I am willing to take this risk because it should be very managable. Good work! -Michael >=20 > (...) >=20 > Best regards, > Wolfgang >=20 --===============4478579403271347079== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxtYXhGRUFDZ2tRZ0hudy8yK1EKQ1FmbHBBLytNMVNiR1Z5WWdw QkZxL0NpNVhNM0FMY2l5QTVLeWxvZXJwSUtEMHlPOXVaRHI1QTFuSmduS2w2MApCVllnWFFOaDd4 MDNFVEMzZTFzdVV4VnNxRVE0V2dNTWZZa2NmdStYclZ1dDNqWXRPSHhUQXdtcTRHekRzU2o1CkVo cW9VMUkvTGt6UWVCaDRPWk5xZGkyRlFJdnNybktLN1g1MWdQU1F1YmFuSC9SWnA3U2luTmxRVGhC bTh1Y00KNkhWQWdnOGQrM1lwVmdmSm4zV1R4WDhqUTNhUFB3VndKOWxhVTNsUCtZbWU2QWZCWFlJ M1NzZjV2aW9kV3FaYgpqdHJhcDVCZGpmQlRwVzAremJuVFc0NHdqdWVuWXFnUTAwdlpGNmR3Tno4 RnRyOXE0TmRlL2xaYUpjWi9GUmg1CmxveGF1aGNDM3JCWGpHaWFQYXI0M0dYU1c3UFZTbTdYRWhT N1lUTWVoanA0aTJtaEIrdHFQb0tlSlVIbHN6Z0gKaHljR1ZJOEY4d0FqQVhIS0hJWE5JT254aUVw ZmYzMU5GNU9MY1ZNZFBEQ0RINFMwbENHMk1YMnlGM1BoOHVNYQp3b2I5L1dqUnA2VlBIejJVb2Fl UzVndzJ1WTduODA3bUY4SytqS2dyQTllS3BQTnRKQUZxQUpSdXZJdFpQMDYzCkhKTnZyL1pWQm1U OE1Na2xwMWxmVHhoUjkxK2JTVlhlemx6a0ZJWHkrWlhvOG5GYzJUaHdlVTlUQzV3NTNFbHcKdlVn K0NkbTlUZzhoU2FMWjZneG5KMWd2RkF0SDRrclBBcHdubTJ2QytRdFVWTTJpY3BaN3V1ZnBsZmlm cEpUdAp0VUNpL0xjZ1YxTndsUHdkeXJyR2hXdmFBN2xYRVg1UGNLVTFadCtFb3NJNVJreG1YSzA9 Cj1uM0hkCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============4478579403271347079==--