requesting policy for Apache module installation (LoadModule manipulation)

Chris H bsd-lists at
Wed Oct 18 17:24:50 UTC 2017

On Wed, 18 Oct 2017 02:16:37 +0200 Miroslav Lachman <000.fbsd at> 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",
>        "pre-deinstall":"/usr/local/sbin/apxs -e -A -n php5"
>     },
> mod_xsendfile uses
>     "scripts":{
>        "post-install":"/usr/local/sbin/apxs -e -A -n xsendfile 
> /usr/local/libexec/apache24/",
>        "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 
> 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

Thanks again, for bringing this up.


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 mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

More information about the freebsd-ports mailing list