Nixpkgs: Rethink httpd subservices

[ericsagnes]

Issue description

Apache httpd has a sub-services functionality that can be used to easily setup web applications.

This is a very handy feature, but that have a few shortcomings that should be addressed:

• Sub-services are tied to httpd, there is no way to use them with a different server.
• The whole sub-service functionality is not well documented.
• The sub-service code is slightly complicated and not well maintained.

Also, sub-services have very few code that is httpd specific (mainly extraConfig).

A way to address this problem could be:

• untie sub-services from httpd and move them to services (or any other fitting namespace)
• In case the configuration is non-trivial, server specific configurations could be added as options to the service (services.mediawiki.httpdConfiguration)

Pseudo-code:

services.mediawiki = {
  enable = true;
  # other settings...
};

services.httpd = {
  enable = true;
  enablePHP = true;
  extraConfig = ''
    # some configuration
    
    # optional, should only be provided if the configuration is non-trivial
    ${config.services.mediawiki.httpdConfig}
  '';
};

This could bring a few advantages:

• sub-services becomes normal modules and can be used with any server.
• server configuration is a normal option and can be overriden or not used according to the needs.

[edolstra]

See also https://github.com/NixOS/nixpkgs/issues/6960.

The problem with services.mediawiki is that it makes it hard to support multiple vhosts or even (if we ever implement this) multiple httpd instances. It's also (IMHO) more readable to have web services underneath the web server. For instance, you can look at services.httpd.virtualHosts."nixos.org".extraSubservices to see what services are running on that vhost. The main problem here is subservices don't interact well with the module system.

[ericsagnes]

The problem with services.mediawiki is that it makes it hard to support multiple vhosts or even (if we ever implement this) multiple httpd instances.

Correct, but it also the case for any regular web service in the module system such as gitlab or redmine. Also, this can be solved by putting the service in a container and having the host server acting as a reverse proxy. Using containers is also the only way if 2 subservices need different PHP versions.

For instance, you can look at services.httpd.virtualHosts."nixos.org".extraSubservices to see what services are running on that vhost. The main problem here is subservices don't interact well with the module system.

The other main problem is that if an user wants to use mediawiki with nginx, he has to implement lot of things including the mediawiki derivation as it is tied to the httpd mediawiki submodule.

[fpletz]

Would it maybe make sense for the PHP applications to use php-fpm to decouple them from a specific HTTP server? Then an only a FCGI abstraction for every HTTP server would be needed.

[ericsagnes]

Would it maybe make sense for the PHP applications to use php-fpm to decouple them from a specific HTTP server? Then an only a FCGI abstraction for every HTTP server would be needed.

That indeed sound like a good approach, the only tricky part is how to set the server configuration for the service (redirects & co). As this configuration can get pretty verbose, it would be nice to have some mechanism to automagically set it up.

I noticed there is a selfoss service that set a php-fpm pool to be run with nginx. The service itself doesnt declare any server configuration at all so I guess it has to be done manually with services.nginx.httpConfig. It look like a step in the right direction.

[grahamc]

Some notes: Upgrading the webapps as they are is an absolute bear, and very difficult to test if they work. The php-fpm mechanism described by @fpletz sounds great. Automatigic configuration of redirects and what-not seems like a good second step, but one we can safely skip for now. The current mechanism is very difficult to configure and understand, I think. I think using containers per application is way overboard as it really cuts down on your hosting capacity for little gain. Apache can support multiple PHP versions at once using .htaccess and per-vhost configuration, IIRC.

Also: color me interested in this issue. :)

[ericsagnes]

Closing in favor of #22067.