This makes the installation a bit more secure by ensuring a user does not accidentally expose a way for unauthorized users to add new ssh keys to the system.
Additionally, this removes the extra HOSTNAME file to make the initial install process easier (that file was not modifiable by any dokku commands.
Closes#2247
This is useful when there is a service not managed by Dokku but should be exposed via the Dokku routing layer. As an example, some binaries (consul, nomad, vault) expose web uis, and are traditionally run on the host directly vs in a container.
Closes#4665
GLOBAL_VHOST_PATH and GLOBAL_VHOST_FILE were used to represent the same
thing. Same for APP_URLS_PATH and APP_VHOST_PATH.
This normalizes all of those to _PATH.
This change allows users to specify a custom nginx.conf.sigil that can expose non-web process types to the outside world in addition to the web process type.
Closes#3258
This enables the HSTS header by default when an SSL certificate is in use. HSTS options can also be managed via the nginx:set command, which also exposes the ability to disable HSTS for your application.
This change allows supporting the openresty package as installed on Ubuntu 18.04 from the official openresty package repository, while also returning general nginx support.
Closes#3675
This will allow background processes to cleanup these files if they were unable to be cleaned up during a run of the dokku binary, as is the case for files copied by the docker binary when running in docker.
While I do not agree with _every_ style change, this will force Dokku to have consistent formatting across all shell scripts, which is arguably a Good Thing™.
The command used to reprocess everything is:
```shell
shfmt -l -bn -ci -i 2 -w .
```
- expose an nginx:validate command that can be used to show validation information
- properly reference the invalid nginx config, rather than tell the user that another app's nginx config is invalid when deploying their own app
- allow a user to cleanup bad nginx config files out of band when they are blocking a deploy _without_ requiring knowing where that nginx config is
Note that this may have issues with generated nginx.conf files that depend on other apps or other parts of the nginx config. For now, this is acceptable, though it is something that needs to be field tested.
Closes#3162
This avoids cases where a developer believes they should be able to provision an nginx proxy but is unable to as no web process is configured to listen for the app.
Also silence stderr when extracting custom nginx templates. If there is stderr, that means we were not able to retrieve the template, but it's of no consequence for debugging.
Closes#3262
