[Bug 225005] Apache modules are touching user modified config file httpd.conf

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225005

            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 at FreeBSD.org
          Reporter: 000.fbsd at quip.cz
                CC: freebsd-ports-bugs at 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 (deinstall)
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 module
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 can
show the right command "apxs -e -a -n php5 libphp5.so" or "apxs -e -a -n
xsendfile 
mod_xsendfile.so" so the user can simply run one command to enable the module)

2) install *.sample file for each module in to apache24/modules.d/ and if user
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.