requesting policy for Apache module installation (LoadModule manipulation)

[Chris H]

On Wed, 18 Oct 2017 02:16:37 +0200 Miroslav Lachman <000.fbsd at quip.cz> wrote

> Hello,
> I would like to ask some changes in how Apache modules are installed.
> There are many maintainers and many different sources for Apache 
> modules. Some modules are installing sample files, some are modifying 
> httpd.conf (LoadModule line) after each install / deinstall.
> 
> The modification after each deinstall is really a mess. If I installed 
> mod_xsendfile, enabled it in httpd.conf and later will use pkg upgrade 
> it will modify my httpd.conf in unwanted way - the mod_xsendfile will be 
> disabled. Same applies to many other modules.
> 
> Some modules (mod_php) is installed and enabled by default. (different 
> behaviour for different modules? Why?)
> 
> Can this behaviour be changed (unified) for all Apache modules to not 
> touch these lines (modules enabled by user)?
> 
> If some port install some config file and user did some changes, this 
> file must not be deleted by deinstalling the port so why Apache modules 
> can remove / comment out lines touched by users?
> 
> Broken Apache webserver after each pkg upgrade is really annoying.
> 
> 
> Making all ports use the same script post-install / post-deinstall would 
> be nice too.
> 
> For example mod_php uses
> 
>     "scripts":{
>        "post-install":"/usr/local/sbin/apxs -e -a -n php5 libphp5.so",
>        "pre-deinstall":"/usr/local/sbin/apxs -e -A -n php5 libphp5.so"
>     },
> 
> mod_xsendfile uses
> 
>     "scripts":{
>        "post-install":"/usr/local/sbin/apxs -e -A -n xsendfile 
> /usr/local/libexec/apache24/mod_xsendfile.so",
>        "post-deinstall":"/usr/bin/sed -i '' -E 
> '/LoadModule[[:blank:]]+xsendfile_module/d' 
> /usr/local/etc/apache24/httpd.conf\necho \"Don't forget to remove all 
> mod_xsendfile-related directives in your httpd.conf\""
>     }
> 
> to achieve the same results (broken httpd.conf)
> 
> mod_php uses pre-deinstall
> mod_xsendfile uses post-deinstall
> 
> mod_php enables mod_php on installation by apxs -e -a
> mod_xsendfile adds commented line by apxs -e -A
> 
> This is just example of two modules. I looked at more modules and they 
> are almost unique - each using different targets, different apxs options 
> etc.
> 
> I am proposing not touching httpd.conf on deinstall at all and just 
> printing the warning that the corresponding LoadModule line should be 
> removed if it is no longer necessary. (by running apxs command?)
> 
> Also use "apxs -e -A -n moduleName" on install only if there is no 
> LoadModule line for this module:
> 
> "post-install":"/usr/bin/grep -E '^#?LoadModule.*php5_module' 
> /usr/local/etc/apache24/httpd.conf || /usr/local/sbin/apxs -e -A -n php5 
> libphp5.so"
> 
> Another way to achieve this can be separate file in apache24/modules.d/ 
> installed as sample and if user wants to enable it, just rename it to 
> moduleName.conf. Then it will not be touched by pkg upgrade / deinstall 
> phase.
Thank you for bringing this up, Miroslav. This has always annoyed me
as well -- and I'm a Module maintainer. :)
If it were up to me;

Installing a Module would:
 o search for the Module line in httpd.conf (commented/uncommented)
 o create a commented line (if not exist)
 o present a banner regarding the [httpd.conf] line

DeInstalling a Module would:
 o search for the Module line (commented/uncommented)
 o nuke the line (if exists)
 o produce a banner regarding what happened

I don't think this method is too intrusive (regarding httpd.conf)
because if the Module line doesn't exist; placing a commented line,
and providing a banner as to how to Activate it, is/should be expected.
OTOH removing a Module line on a Module you are UNinstalling should
be expected; as the Module no longer exists, and can no longer be
enabled. This process should also present a banner, as to what just
occurred.

Thanks again, for bringing this up.

--Chris

P.S. IMHO this probably should have been prefaced with [RFC]
eg; [RFC] Policy for Apache Module Installation / Deinstallation
just my 2¢ :)
> 
> Miroslav Lachman
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"