180

We all know how to enable a website using apache on Linux. I'm pretty sure that we all agree on using the a2ensite command.

Unfortunately, there is no default equivalent command that comes with Nginx, but it did happen that I installed some package on ubuntu that allowed me to enable/disable sites and list them.

The problem is I don't remember the name of this package.

Does anybody know what I'm talking about?

Please tell me the name of this package and the command name.

HXH
  • 2,905
  • 2
  • 17
  • 13

10 Answers10

256

If you have installed the nginx package from the Ubuntu repositories, you will have two directories.

/etc/nginx/sites-enabled and /etc/nginx/sites-available.

In the main nginx configuration, /etc/nginx/nginx.conf, you have the following line:

include /etc/nginx/sites-enabled/*.conf;

So basically to list all available virtualhosts, you can run the following command:

ls /etc/nginx/sites-available

To activate one of them, run the following command:

ln -s /etc/nginx/sites-available/www.example.org.conf /etc/nginx/sites-enabled/

The scripts that comes with Apache is basically just simple shell wrappers that does something similar as above.

After linking the files, remember to run sudo service nginx reload/ service nginx reload

Drifter104
  • 3,693
  • 2
  • 22
  • 39
pkhamre
  • 5,900
  • 3
  • 15
  • 27
  • 7
    Yeah I know how to that using the command line, thanks – HXH Sep 05 '12 at 09:02
  • 36
    Then I am unsure what you are really asking for. – pkhamre Sep 05 '12 at 09:04
  • 4
    remember to reload nginx server with: sudo service nginx reload – Ricardo Martins Jan 23 '13 at 11:34
  • 25
    @pkhamre: When using Apache there are two scripts: a2ensite and a2dissite. They simply create and delete the symbolic links you describe, so they are faster ways of enabling and disabling. – Mads Skjern Aug 20 '14 at 19:59
  • 10
    Thanks for the constant upvotes on this old answer. If OP would accept this answer it would be epic :) – pkhamre Dec 16 '16 at 09:08
  • 2
    Indeed it'd be epic, but OP would never accept your answer, just look at his last edit of the question! In fact, I provided a full non-Debian-specific answer below (as `sites-enabled` is Debian/Ubuntu-specific), only to receive an almost immediate downvote from the OP, along with the comment that somehow their massive-for-nothing third-party script is easier to use than a single `mv` or `ln` invocation. It looks like they've downvoted every single answer other than their own! If only the rest of us would be as generous with our downvotes! – cnst Aug 31 '17 at 16:27
  • 1
    The files in the `sites-available` or `sites-enabled` do not have to end with `.conf`. The above mentioned line in `nginx.conf` is not correct. The real one includes just anything: `include /etc/nginx/sites-enabled/*`. (The `/etc/nginx/conf.d/` directory works differently though.) – jox Nov 22 '17 at 13:53
  • It was correct at the time of the answer. – pkhamre Dec 04 '17 at 12:56
  • Actually I don't have `include /etc/nginx/sites-enabled/*.conf;` in my nginx.conf file or anywhere, but it stills load files in that directory – Handsome Nerd May 28 '20 at 01:14
91

Just create this script /usr/bin/nginx_modsite and make it executable.

#!/bin/bash

##
#  File:
#    nginx_modsite
#  Description:
#    Provides a basic script to automate enabling and disabling websites found
#    in the default configuration directories:
#      /etc/nginx/sites-available and /etc/nginx/sites-enabled
#    For easy access to this script, copy it into the directory:
#      /usr/local/sbin
#    Run this script without any arguments or with -h or --help to see a basic
#    help dialog displaying all options.
##

# Copyright (C) 2010 Michael Lustfield <mtecknology@ubuntu.com>

# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.

##
# Default Settings
##

NGINX_CONF_FILE="$(awk -F= -v RS=' ' '/conf-path/ {print $2}' <<< $(nginx -V 2>&1))"
NGINX_CONF_DIR="${NGINX_CONF_FILE%/*}"
NGINX_SITES_AVAILABLE="$NGINX_CONF_DIR/sites-available"
NGINX_SITES_ENABLED="$NGINX_CONF_DIR/sites-enabled"
SELECTED_SITE="$2"

##
# Script Functions
##

ngx_enable_site() {
    [[ ! "$SELECTED_SITE" ]] &&
        ngx_select_site "not_enabled"

    [[ ! -e "$NGINX_SITES_AVAILABLE/$SELECTED_SITE" ]] && 
        ngx_error "Site does not appear to exist."
    [[ -e "$NGINX_SITES_ENABLED/$SELECTED_SITE" ]] &&
        ngx_error "Site appears to already be enabled"

    ln -sf "$NGINX_SITES_AVAILABLE/$SELECTED_SITE" -T "$NGINX_SITES_ENABLED/$SELECTED_SITE"
    ngx_reload
}

ngx_disable_site() {
    [[ ! "$SELECTED_SITE" ]] &&
        ngx_select_site "is_enabled"

    [[ ! -e "$NGINX_SITES_AVAILABLE/$SELECTED_SITE" ]] &&
        ngx_error "Site does not appear to be \'available\'. - Not Removing"
    [[ ! -e "$NGINX_SITES_ENABLED/$SELECTED_SITE" ]] &&
        ngx_error "Site does not appear to be enabled."

    rm -f "$NGINX_SITES_ENABLED/$SELECTED_SITE"
    ngx_reload
}

ngx_list_site() {
    echo "Available sites:"
    ngx_sites "available"
    echo "Enabled Sites"
    ngx_sites "enabled"
}

##
# Helper Functions
##

ngx_select_site() {
    sites_avail=($NGINX_SITES_AVAILABLE/*)
    sa="${sites_avail[@]##*/}"
    sites_en=($NGINX_SITES_ENABLED/*)
    se="${sites_en[@]##*/}"

    case "$1" in
        not_enabled) sites=$(comm -13 <(printf "%s\n" $se) <(printf "%s\n" $sa));;
        is_enabled) sites=$(comm -12 <(printf "%s\n" $se) <(printf "%s\n" $sa));;
    esac

    ngx_prompt "$sites"
}

ngx_prompt() {
    sites=($1)
    i=0

    echo "SELECT A WEBSITE:"
    for site in ${sites[@]}; do
        echo -e "$i:\t${sites[$i]}"
        ((i++))
    done

    read -p "Enter number for website: " i
    SELECTED_SITE="${sites[$i]}"
}

ngx_sites() {
    case "$1" in
        available) dir="$NGINX_SITES_AVAILABLE";;
        enabled) dir="$NGINX_SITES_ENABLED";;
    esac

    for file in $dir/*; do
        echo -e "\t${file#*$dir/}"
    done
}

ngx_reload() {
    read -p "Would you like to reload the Nginx configuration now? (Y/n) " reload
    [[ "$reload" != "n" && "$reload" != "N" ]] && invoke-rc.d nginx reload
}

ngx_error() {
    echo -e "${0##*/}: ERROR: $1"
    [[ "$2" ]] && ngx_help
    exit 1
}

ngx_help() {
    echo "Usage: ${0##*/} [options]"
    echo "Options:"
    echo -e "\t<-e|--enable> <site>\tEnable site"
    echo -e "\t<-d|--disable> <site>\tDisable site"
    echo -e "\t<-l|--list>\t\tList sites"
    echo -e "\t<-h|--help>\t\tDisplay help"
    echo -e "\n\tIf <site> is left out a selection of options will be presented."
    echo -e "\tIt is assumed you are using the default sites-enabled and"
    echo -e "\tsites-disabled located at $NGINX_CONF_DIR."
}

##
# Core Piece
##

case "$1" in
    -e|--enable)    ngx_enable_site;;
    -d|--disable)   ngx_disable_site;;
    -l|--list)  ngx_list_site;;
    -h|--help)  ngx_help;;
    *)      ngx_error "No Options Selected" 1; ngx_help;;
esac

How it works:

To list all the sites

$ sudo nginx_modsite -l

To enable site "test_website"

$ sudo nginx_modsite -e test_website

To disable site "test_website"

$ sudo nginx_modsite -d test_website
HXH
  • 2,905
  • 2
  • 17
  • 13
  • in ngx_relaod function, I commented out the read and just make reload="y" since I run this via cron and didn't want the prompt at all. Thanks! – radtek Nov 04 '14 at 19:16
  • yeah it make the perfect sense, can you tell me where did you make the change? – HXH Nov 05 '14 at 20:25
  • search for ngx_reload() , comment out the 1st line of the function and replace with reload="y" – radtek Nov 05 '14 at 20:53
  • 27
    A pretty large script to wrap some standard one line commands. – tobltobs Jun 02 '16 at 14:30
  • 2
    @tobltobs Good programmers write code, great programmers steal code :) This makes a nice add to my collection of server imaging scripts. – Matt Borja Jul 10 '16 at 13:39
  • 12
    @GhassenTelmoudi as the script you keep mentioning is a third party script, which is not even packaged by the creators (ubuntu) into the nginx package, your comment suggest to use a third party script over a (one line) command line alternative. This is how security vulnerabilities and unnecessarily complex dependency trees are created – scones Aug 30 '17 at 21:40
  • 1
    Note that you dual-licensed the code: the footer of the page says user contributions are creative commons with attribution required, and your code has its own license. I'm pretty sure that means one may use it under either terms. Honestly, I think including a license in your stackexchange snippet is rather overkill... – Luc Feb 02 '19 at 11:49
  • @HXH There were 2 concerns with Your script: 1. the nginx config wasn't checked before enabling and reloading. When enabling a faulty additional config file, everything (except the new config isn't really loaded) seems fine until nginx is restarted. 2. the script except everything (besides "n" or "N") for reloading. Better is to except only "y" or "Y". My version is here: https://gist.github.com/sneakyx/dce625f3b71be5a6f2a2388b14b97928 – sneaky Sep 16 '22 at 09:20
36

There's third-party nginx_ensite and nginx_dissite available.

Can be installed as quick as

git clone https://github.com/perusio/nginx_ensite.git
cd nginx_ensite
sudo make install

(see the repo, though)

Example usage: nginx_ensite example.org (see more at online man page).

YakovL
  • 117
  • 6
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 22
    This is barely an answer, is it? These commands are not present on my installation of nginx, on Ubuntu installed with apt-get. It seems like it is just a 3rd party script: https://github.com/perusio/nginx_ensite – Mads Skjern Aug 20 '14 at 19:53
  • 3
    First of all, thanks for answering :) And sorry for my comment, which perhaps sounds offensive, when I actually only wanted to point out that it was not very useful for me (at the time), because of it assuming too much from the reader. – Mads Skjern Mar 23 '15 at 09:32
  • 29
    You answered with two commands and a url, and even in the form of a question. As someone with my low level of experience, your answer would have sent me out there googling. Maybe I would find a helpful guide/tutorial/demo in 2 minutes, maybe I would be looking around for an hour and still be confused. What would have helped me back then was: "There are these tools nginx_ensite and nginx_dissite, it is a 3rd party script, download it from here, and they work this way, example, example". Ghassen's answer is more elaborate, more introductory, more helpful. I hope you understand what I mean :) – Mads Skjern Mar 23 '15 at 09:32
  • 12
    @MadsSkjern Well, you could have just clicked the link. :) – Michael Hampton Mar 23 '15 at 15:17
5

NGINX

If you're using one of the official upstream packages of nginx from http://nginx.org/packages/, the best way is to navigate to the /etc/nginx/conf.d directory, and rename the affected file from having a .conf suffix to having a different one to disable the site:

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

Or the opposite to enable it:

sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}

This is because the default /etc/nginx/nginx.conf has the following include directive:

http {
    …
    include /etc/nginx/conf.d/*.conf;
}

Debian/Ubuntu

However, if you're using a Debian/Ubuntu derivative, then in addition to conf.d, you may also have the evil non-standard sites-available and sites-enabled directories, some files under which may be sloppily included without regard to their extension:

http {
    …
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

As such, in Debian/Ubuntu, you might first have to figure out where the site config is located.

  • You could use the following command to get a list of all available sites by running find(1) to find all regular files matching the given mask:

    find /etc/nginx -maxdepth 2 -type f \( -path "*/conf.d/*.conf" -or -path "*/sites-*/*" \)

  • You could use the following command to get a list of all enabled sites:

    find /etc/nginx -maxdepth 2 \( -path "*/conf.d/*.conf" -or -path "*/sites-enabled/*" \)

Then to disable/enable sites on Debian/Ubuntu:

  • To disable a site: if the config is in conf.d, just rename the file to no longer have a .conf suffix; or if in sites-enabled, move it out of sites-enabled.

  • To enable a site, the best way would be to move it to /etc/nginx/conf.d, and rename to have a .conf suffix.

P.S. Why do I think Debian's include /etc/nginx/sites-enabled/*; is evil? Try editing a couple of files in that directory, and have your emacs create the backup files (with the ~ suffix), then ask me again.

cnst
  • 12,948
  • 7
  • 51
  • 75
  • 9
    I'd like to point out that the issue with this answer lies in two erroneous assumptions regarding Debian and derivatives: 1) The purpose of `conf.d` directory is server-wide configuration like that for modules, plugins, fastcgi handlers etc and explicitly **not** to store host/vhost configurations in and 2) One **should not** edit any files in `sites-enabled` https://serverfault.com/a/825297/86189 – Bojan Markovic Sep 05 '17 at 11:14
  • @BojanMarkovic, you are wrong. You cannot serve server-wide configurations in `conf.d`, because it is included at the same context as the `sites-enabled` one — `http`-level context, so, module and plugin directives may not apply. Likewise, your assumption that one should not edit files in `sites-enabled` is merely wishful thinking — there are no such instructions within the distro, or within the directory, so, it's purely your assumption, which is in no way enforced by the distribution, so, you have all sorts of issues arising out of it, e.g., https://stackoverflow.com/q/45852224/1122270. – cnst Sep 05 '17 at 17:54
  • 2
    The issue you pointed at has absolutely no connection to this. I am wrong about `conf.d` as is , probably, the Debian maintainer of Nginx (or perhaps it's kept for compatibility with upstream). About not editing files in `sites-enabled`, it's not wishful thinking but the supposed worflow under Apache which they tried to emulate on Nginx. In apache it's quite obvious due to existance of `a2ensite` and `a2dissite` scripts. Unfortunately nothing of the sort is provided for Nginx which shows how low the maintainance quality of that package is on Debian. Both lack documentation, true. – Bojan Markovic Sep 07 '17 at 08:12
  • 3
    ..I'll give you that (docs are abysmally lacking in this regard). However you're the first person running web servers on Debian I've talked to that was confused by this. Just a simple `ls -al sites-enabled` in either Apache or Nginx shows that the existing files in the directory are symlinks from `-available`, ditto for modules under Apache, along with provided `a2enmod`/`a2dismod` scirpts. – Bojan Markovic Sep 07 '17 at 08:15
  • You should consider to learn a bit about Debian before arguing that we are all plain wrong. In no way you must edit files in the *-enabled directories. All Debian administrators are aware of this fact. Debian is not a Redhat like distribution where almost all is permitten without further care. Yes, editing a conffile through a symlink that you should ignore can lead to issue. That is a fact that any Debian administrator will know. Debian people like to provide rules and convenience tools to ease administration. Newbies cannot manage a Debian server without learn first. – Laurent DECLERCQ a.k.a Nuxwin Jan 21 '18 at 09:42
  • 1
    @Nuxwin, 2007 called, they want their learn-first-manage-later approach back. Noone learns the whole system anymore; I've also been using Debian for a quite a long time, and have never encountered a similar braindead available/enabled setup with any other package, especially for files that are meant to be user-generated and user-editable (e.g., comparing this with rc.d would not be appropriate). The amount of problems this setup generates speaks for itself. – cnst Jan 22 '18 at 21:12
  • Fascinating discussion. At it's core is Apache vs Nginx. Nginx says: https://www.nginx.com/blog/nginx-vs-apache-our-view/ – pzrq Feb 06 '18 at 08:03
  • Nginx links to Netcraft which from their website appears to be a reputable security firm, and in my spot checks Netcraft appears to show Nginx is increasing and Apache decreasing (though still very strong): https://news.netcraft.com/archives/2018/01/19/january-2018-web-server-survey.html#more-26159 – pzrq Feb 06 '18 at 08:45
  • Ubuntu is about equal with CentOS (i.e. free Red Hat Enterprise Linux): https://www.similartech.com/compare/centos-vs-ubuntu – pzrq Feb 06 '18 at 08:45
  • A wildcard is Amazon Linux is based on Red Hat and CentOS, https://www.exratione.com/2014/08/do-not-use-amazon-linux/ and Google Cloud Platform seems to have a preference for Debian (Ubuntu), https://cloud.google.com/compute/docs/quickstart-linux and Azure supports both families. https://docs.microsoft.com/en-us/azure/virtual-machines/linux/overview#azure-virtual-machines--instances – pzrq Feb 06 '18 at 08:45
  • I think it appears that because Apache and Nginx are evenly split, and Ubuntu (Debian) and CentOS (Red Hat, Amazon Linux) appear evenly split, the overall standard today isn't clear. However, ask this question in 5 years and you may get a very different answer depending on how the Ubuntu vs CentOS trends play out. – pzrq Feb 06 '18 at 08:46
  • There's also a vim vs emacs vs nano vs undercurrent lurking here... I'm not sure what to make of that. – pzrq Feb 06 '18 at 08:50
  • In short, while in an ideal world sysadmins would just learn the Nginx official configuration as @cnst argues, in practice learning the Debian/Ubuntu-branded version has value if one needs to migrate their organization off of Apache. Learning is hard =) – pzrq Feb 06 '18 at 08:53
  • 1
    @pzrq, you're equating a lot of unrelated things; the available/enabled has nothing to do with apache nor debian; failing evidence to the contrary, it's basically just something that some maintainer sneaked into the right place at the right time when noone was looking, and it stuck; there's little reason to continue using it if you're already spending the resources to transition to nginx, which would already require config rewrites to get rid of .htaccess, for example — might as well standardise your config with all the clouds and distros in mind, which is easy enough with `conf.d` as-is. – cnst Feb 06 '18 at 21:25
  • I disagree that they are unrelated (having had to just solve this problem myself for RHEL+CentOS+Debian+Ubuntu), I stand by learning (and indeed communication) is hard =) – pzrq Feb 08 '18 at 01:32
3

Link with full path:

ln -s /etc/nginx/sites-available/site_1.conf /etc/nginx/sites-enabled/
service nginx reload
  • This doesn't contain the full path to the link destination so it will be created relative to the current directory, which is probably not what you want. – Michael Hampton Aug 20 '21 at 20:45
2

Compact ngensite/ngdisite shell scripts

After reading the replies here while setting up a new Debian server, then going off to do some research, I made a couple of readable shell scripts to help me enable/disable sites on a server with at least some security (root disabled, non-default ports, etc.). Once the files are executable with chmod +x anyone with root access can call these scripts from anywhere as /usr/local/bin/ is in the Debian PATH by default.

These work (the way I've used for years) by creating and deleting aliases in sites_enabled so don't touch the contents of virtual hosts files in sites_available.

Enable site

in: /usr/local/bin/ngensite:

#!/bin/sh
read -p "Website to enable: " site;
ln -s /etc/nginx/sites-available/"$site" /etc/nginx/sites-enabled/
echo "$site enabled. Now run 'service nginx reload'"

Then from the command-line: sudo ngensite

(The prompt will need the exact nginx virtualhosts config file).

Disable site

in: /usr/local/bin/ngdissite:

#!/bin/sh
read -p "Website to disable: " site;
rm /etc/nginx/sites-enabled/"$site"
echo "$site disabled. Now run 'service nginx reload'"

Then from the command-line: sudo ngdissite

(The prompt requires the exact name of the nginx virtualhosts config file).


If you spot any issues in these (they're very simple but do the job for me) please comment.

Dave Everitt
  • 181
  • 2
  • 11
0

I know it's not technically correct, but I just mv the config in sites-available to sites-enabled. It works fine, don't live a complicated life.

Jonathan
  • 252
  • 1
  • 13
0

To enable:

ln -s /etc/nginx/sites-available/site /etc/nginx/sites-enabled/

To disable:

unlink /etc/nginx/sites-enabled/conf
assayag.org
  • 109
  • 1
0

I want to submit my script written in Bash to accommodate this feature. It's called nginxsitehttps://github.com/L1so/nginxsite/. For more info check the github link.


Enabling

To activate a site, replace (YOUR SITE) with your actual site domain (located in /etc/nginx/sites-available/).

sudo ngxensite (YOUR SITE)

Disabling

To deactivate a site, replace (YOUR SITE) with your actual site domain (located in /etc/nginx/sites-available/).

sudo ngxdissite (YOUR SITE)

Create server block

To create a site, replace (YOUR DOMAIN) with your actual domain.

sudo ngxcreate (YOUR DOMAIN)

Running ngxcreate without any argument will give you a prompt to enter desired site name, if you don't include tld, the script will give you .com domain.

$ sudo ngxcreate
Please Enter a Domain Name (default TLD is .com):
examplesite

Will save a new file named /etc/nginx/sites-available/examplesite.com

Delete server block

To delete a site, replace (YOUR DOMAIN) with your actual site domain.

sudo ngxdelete (YOUR DOMAIN)

Example given below.

root@mutiny:~# ngxdelete bar.co 
Removing --> /etc/nginx/sites-available/bar.co
Liso
  • 63
  • 6
0

Another method is just to rename the site's config file to something that ends without .conf

E.g. sudo mv mysite.conf mysite.conf.disabled

Then reload nginx, and that vhost will fall back to the default.

Yoseph
  • 128
  • 4
  • it's always nice to use the nginx_modsite command, you can list, disable, enabled site much easier and faster, than renaming the file every time @Pyrite – HXH May 19 '15 at 18:24
  • It doesn't appear that nginx_modsite is installed by default. Yet renaming files is a stock option. Besides, I prefixed my answer as an alternate method, not the best method @GhassenTelmoudi – Yoseph May 25 '15 at 11:07
  • 4
    @Pyrite On Ubuntu 14.04 the extension doesn't mater as nginx.conf includes sites-enabled as `include /etc/nginx/sites-enabled/*;` it only includes conf dir as `*.conf` – Bojan Markovic Jul 05 '15 at 17:45
  • 3
    @GhassenTelmoudi as the script you keep mentioning is a third party script, which is not even packaged by the creators (ubuntu) into the nginx package, your comment suggest to use a third party script over a (one line) command line alternative. This is how security vulnerabilities and unnecessarily complex dependency trees are created. – scones Nov 04 '16 at 11:45
  • @BojanMarkovic, yes, Debian and Ubuntu is evil — https://serverfault.com/a/870618/110020 — their wildcast of any file is especially troublesome if you edit files directly in `sites-enabled`, and your editor creates the backup files. – cnst Aug 26 '17 at 20:49
  • 2
    @cnst I wouldn't go as far as call it evil, especially their choice of `sites-available` and `sites-enabled` as they do have merit and use. Somebody should probably just file a bug report for the true offending line in nginx conf to `/etc/nginx/sites-enabled/*.conf;` and they probably will as it's probably an oversight. But if you respect the Debian workflow you'll be editing files in `sites-available` anyway and symlinking the ones you want enabled into `sites-enabled`. – Bojan Markovic Sep 04 '17 at 09:44
  • @BojanMarkovic, the name of their default.conf file is just `default`, so, it's clearly intentional, and would never be fixed due to backwards-compatibility concerns. Moreover, why use symlinks? Why not just `mv`? What's the purpose of the extra files lying around on the filesystem? This sheer number of uncertainties and edge-cases make `sites-enabled` quite evil, indeed. – cnst Sep 04 '17 at 19:48
  • 2
    @cnst The *why* is quite self-evident isn't it? It enables you to enable and disable vhosts without deleting them, in a way that is **identical** on both apache and nginx. The fact that *you* are exclusively interested in nginx doesn't invalidate Debian maintainers' intent of providing the similar enable/disable method for both web servers. – Bojan Markovic Sep 05 '17 at 11:10
  • @BojanMarkovic, why would you want to have identical workflow between apache and nginx? They're different servers, and if you're striving for identicity, you're probably doing it wrong. Moreover, you completely ignore the point that no deleting of files is requires in the `conf.d` case, whereas `sites-available`, on the other hand, does require file deletion, which in big teams can create quite some funny issues — https://stackoverflow.com/a/45854512/1122270. – cnst Sep 05 '17 at 18:05
  • 1
    @cnst the issue you pointed at has absolutely no connection to this. the same thing would happen if they kept the vhost configuration in `conf.d`. – Bojan Markovic Sep 07 '17 at 08:07