From owner-freebsd-ports-bugs@freebsd.org Mon Jan 8 16:59:14 2018 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 963ABE778CE for ; Mon, 8 Jan 2018 16:59:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D89820EB for ; Mon, 8 Jan 2018 16:59:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 592832BCF8 for ; Mon, 8 Jan 2018 16:59:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w08GxEZ3049484 for ; Mon, 8 Jan 2018 16:59:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w08GxEMm049483 for freebsd-ports-bugs@FreeBSD.org; Mon, 8 Jan 2018 16:59:14 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 225005] Apache modules are touching user modified config file httpd.conf Date: Mon, 08 Jan 2018 16:59:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: 000.fbsd@quip.cz X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:59:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225005 Bug ID: 225005 Summary: Apache modules are touching user modified config file httpd.conf Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: Ports Framework Assignee: portmgr@FreeBSD.org Reporter: 000.fbsd@quip.cz CC: freebsd-ports-bugs@FreeBSD.org There are mess in 3rd party Apache modules from ports tree. They are messing with user edited config file httpd.conf. They use inconsistent way to manipulate this file. As I already wrote https://lists.freebsd.org/pipermail/freebsd-ports/2017-October/110725.html = some of them uses pre-deinstall, some post-deinstall. But the main problem is they override users settings on each pkg upgrade. If user decided to install AND manually enable some module (for example mod_xsendfile) this module should not modify httpd.conf on upgrade (deinsta= ll) because it leaves Apache in broken state after each upgrade. I think installation of module should not enable it it-self, the same way as services are not enabled in rc.conf on installation. And if user did enable some module, deinstallation must not disable this mo= dule on upgrade. There are tens of Apache modules in the ports tree and I think all of them = must use the same way of install / deinstall. For example - mod_php71 is enabled in httpd.conf on install, removed on deinstall. But mod_xsendfile is added to httpd.conf commented, user uncomment this line and then pkg upgrade (deinstall phase) will remove this line, install will = add it back commented out. It's a real pain to maintain Apache + modules if each are behaving different. The root cause partialy lies in ports/Mk/bsd.apache.mk which is responsible= for manipulating httpd.conf but some ports are using own way to edit httpd.conf. There are two ways (at least) to handle this properly: 1) do not manipulate httpd.conf in any way and just print pkg-message with information what should be added in to httpd.conf manually be user (or we c= an show the right command "apxs -e -a -n php5 libphp5.so" or "apxs -e -a -n xsendfile=20 mod_xsendfile.so" so the user can simply run one command to enable the modu= le) 2) install *.sample file for each module in to apache24/modules.d/ and if u= ser decides to enable module (copy or rename mod_xsendfile.conf.sample to mod_xsendfile.conf) then pkg upgrade / pkg delete should not touch this conf file How-to-reproduce: 1) install Apache 2.4 2) make a copy of directory apache24 # cp -Rp apache24 apache24.1 3) # pkg install ap24-mod_xsendfile 4) # diff -r -u apache24.1 apache24 +#LoadModule xsendfile_module libexec/apache24/mod_xsendfile.so 5) Manually enable this module # sed -i '' -E 's/#(LoadModule.*mod_xsendfile.so)/\1/' apache24/httpd.conf 6) # diff -r -u apache24.1 apache24 +LoadModule xsendfile_module libexec/apache24/mod_xsendfile.so 7) Try to upgrade it: # pkg upgrade -f ap24-mod_xsendfile 8) Here comes the chaos, config file does not have xsendfile at all # diff -r -u apache24.1 apache24 # grep xsendfile apache24/httpd.conf If you use pkg delete + pkg install instead of pkg upgrade -f, then you will have commented LoadModule (disabled xsendfile) in httpd.conf The second example with mod_php is different, mod_php is enabled again even= if user wants module installed (and then upgraded) but keep module disabled: 1) # pkg install mod_php71 2) # diff -r -u apache24.1 apache24 +LoadModule php7_module libexec/apache24/libphp7.so 3) Manually disable the module # sed -i '' -E 's/#?(LoadModule.*libphp7.so)/#\1/' apache24/httpd.conf # grep php7 apache24/httpd.conf #LoadModule php7_module libexec/apache24/libphp7.s 4) run upgrade after some time # pkg upgrade -f mod_php71 5) module is accidentally enabled again # grep php7 apache24/httpd.conf LoadModule php7_module libexec/apache24/libphp7.so 6) and removed in deinstall # pkg delete mod_php71 7) # grep php7 apache24/httpd.conf If there is written policy on how to (not) handle Apache module install / upgrade / deinstall then it should be strictly followed by all modules from ports tree. If policy does not exists then I think it should be created and followed be= all maintainers and committers. --=20 You are receiving this mail because: You are on the CC list for the bug.=