Bug#822792: (no subject)
Sorry for the noise... should quiet down now. :(
Bug#822792: (no subject)
tags 822792 - pending
thanks
We had to pop this off because of other changes that needed to be released.
I've moved these specific changes into their own branch and plan to work on
the change there until we have something ready with other upstream packages so
that we can provide magical installations of web applications.
> 1. After looking at conf/sites-available/default I noticed a
>commented block handling .php files in there.
>
>Would a config file in apps.d be allowed to do exactly
>that? Like apps.d/pkg_php-fpm.conf handling *.php
>files?
Nope! In fact, that's why I'm trying to be very strict with the format of these
files. I don't want packages stepping on each other's toes.
However... I've already covered this use case with conf.d.
https://wiki.debian.org/Nginx/DirectoryStructure#appincludes
"Example: /etc/nginx/conf.d/pkg_drupal8.conf"
In this case, I'd say go ahead and provide /etc/nginx/conf.d/pkg_php-fpm.conf
which would include "upstream _provider_php { ... }". This shouldn't be a
problem unless someone tries to install multiple "php providers."
I'd like to get something like _provider_php available via php-fpm as well as
uwsgi-plugin-php.
Doing it this way would reduce security, but I'm thinking it's to a very
negligible degree and not very concerned.
> 2. Do we have recommended naming for files added by the
>local admin to apps.d?
We could suggest custom_.conf.
--
Michael Lustfield
Bug#822792: (no subject)
After talking to Christos a bit, I think we'll be settling on "apps.d/" instead. I mistakingly pushed this change to our main branch instead of pushing to experimental. This will need to be done while working with other package maintainers to produce quality configurations which is mandatory for this to work. -- Michael Lustfield
Bug#822792: (no subject)
Control: tags 822792 - wontfix > default-server-includes.d/*.conf It seems like an overly verbose name, but seems to also fit the use case. -- Michael Lustfield
Bug#822792: (no subject)
On Sat, Jul 16, 2016 at 07:00:21PM -0700, Michael Lustfield wrote: > Using conf.d/* is a very common practice with web servers. Apache has this > exact same structure. Apache once had this structure, starting with 2.4 (Jessie) it changed to /etc/apache2/conf-available /etc/apache2/conf-enabled and it doesn't have conf.d anymore. Apache then loads everything from /etc/apache2/conf-enabled/*.conf. Admins are exected to put their stuff in conf-available and then run `a2enconf confname` which creates a symlink in conf-enabled to conf-available (then, I hate doing that and I have my ansible role just put my conf files in conf-enabled). Note that for apache files in those directories are not expected to define virtualhosts. > I'm not against modifying the main nginx config file to support this, but I'm > against the proposed solution and not sure I see an obvious solution that > seems > to be sensible. I find apache's solution very sensible, actually. On Tue, Jul 26, 2016 at 10:37:41PM -0700, Michael Lustfield wrote: > Obviously, conf.d/*.conf has been around for a *LONG* time and isn't > going anywhere. Also apache's conf.d has been there for a very long time, but it simply went away :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#822792: (no subject)
Using conf.d/* is a very common practice with web servers. Apache has this exact same structure. Because of the way inheritance works in nginx configuration files, things that would typically work in apache do not work with Nginx. You're requesting we change away from how web server packages typically handle configuration files to something that suits the use of sub-directories for web applications. I'm not against modifying the main nginx config file to support this, but I'm against the proposed solution and not sure I see an obvious solution that seems to be sensible. -- Michael Lustfield
