The shipped catch-all default site uses `ssl_reject_handshake`, which is unsupported on nginx older than 1.19.4 and causes nginx to fail to start on Debian Bullseye. The postinst now detects the installed nginx version and installs an HTTP-only variant of the catch-all on older systems.
Renaming `/etc/nginx/sites-enabled/default` to `.dokku-disabled` left a broken symlink that nginx's `include /etc/nginx/sites-enabled/*;` glob still picked up, breaking config validation. Files inside `sites-enabled/` are now removed; the real config in `sites-available/default` is still preserved via rename.
Fresh apt installs now drop a catch-all server block at `/etc/nginx/conf.d/00-default-vhost.conf` that uses `ssl_reject_handshake on` and `return 444` to drop requests with unknown Host headers. Conflicting upstream nginx default vhosts are renamed to `*.dokku-disabled` rather than deleted, preserving any local edits. The new `dokku/install_default_site` debconf flag opts out of the install. Upgrades leave existing nginx config untouched.
Previously, we would try and traverse the entire dokku lib directory, causing extremely slow updates for installations with lots of data. This would also potentially cause issues for anyone using symlinks in their data directories.
Instead, just remove symlinks in the plugin directories.
This makes standard use of shellcheck work without needing to provide extra configuration anywhere.
Also remove use of inline 'shellcheck disable' calls that are already defined in the .shellcheckrc and don't need to be set inline.
This will continue to not override anyone's global domain preferences, but will at least ensure we set the domain prior to the default injected in 00_dokku-standard#install.
Closes#4065
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
Ideally python usage goes away - the dokku-installer should become a mandatory cli command, and the plugin is rewritten in golang - but for now, we need to use the correct binary when running dokku.
Closes#3714
The version in DOKKU_ROOT may be incorrect for docker-based installs if that directory is mounted from an external volume. Instead, pull it from the DOKKU_LIB_ROOT directory, and respect the STABLE_VERSION if specified (VERSION will be the entire version, including commit sha).
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 .
```
This allows us to force another plugin as the default vhost implementation, or disable it altogether in favor of some higher-level proxy implementation, such as one that integrates with service discovery.
This allows users to override - at a top-level - the DOKKU_ROOT, DOKKU_LIB_ROOT, and other
configuration variables. If specified, this should begin to enable users to move their
Dokku installations to mounted drives.
Note that items installed from packages may not respect these paths, so further work may be in order.
Closes#2958
We previously assumed that systemd was detectable by the existence of certain directories. Unfortunately, it seems 14.04 already has these directories, so we need to handle this case separately.
One other note is that dokku-installer will fail to "start" if already started on certain systems, thus the previous grep was more accurate in it's running.
- Use the nginx.conf file's existence as a check for whether we should start the service or not
- Create the init files with the dokku-installer.py file. This adds actual systemd support.
- Also ensure we *always* start the service, regardless of it's status. This fixes an issue with processing systemd output
We had an issue with third party plugins installing things via apt while
already installing dokku itself via apt.
To resolve this, `plugins-install` and `plugins-install-dependencies`
now can take a `--core` flag allowing to execute the install hook only
on core plugins and not on third party plugins.
Another feature with this modification is the ability to disable/enable
plugins. Two new commands now exist:
* `plugins:enable <name>` to enable a previously disabled plugin
* `plugins:disable <name>` to disable an installed plugin. This won’t
work on core plugins.
