Nginx enable site command

Question

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.

Solution 1

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 <[email protected]>

# 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

Solution 2

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

Solution 3

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).

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[user9517]

The assertion about a2ensite isn't true for CentOS

[HXH]

Yeah I know how to that using the command line, thanks

[pkhamre]

Then I am unsure what you are really asking for.

[Ricardo Martins]

remember to reload nginx server with: sudo service nginx reload

[Mads Skjern]

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: github.com/perusio/nginx_ensite

[Mads Skjern]

@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.

[radtek]

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!

[HXH]

yeah it make the perfect sense, can you tell me where did you make the change?

[radtek]

search for ngx_reload() , comment out the 1st line of the function and replace with reload="y"

[Mads Skjern]

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]

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 :)

[Michael Hampton]

@MadsSkjern Well, you could have just clicked the link. :)

[HXH]

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

[Yoseph]

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

[AlpSenel]

@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

[tobltobs]

A pretty large script to wrap some standard one line commands.

[Matt Borja]

@tobltobs Good programmers write code, great programmers steal code :) This makes a nice add to my collection of server imaging scripts.

[scones]

@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.

[Congmin]

@BojanMarkovic, yes, Debian and Ubuntu is evil — 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.

[scones]

@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

[Congmin]

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!

[AlpSenel]

@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.

[Congmin]

@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.

[AlpSenel]

@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.

[AlpSenel]

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 serverfault.com/a/825297/86189

[Congmin]

@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 — stackoverflow.com/a/45854512/1122270.

[AlpSenel]

@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.

[AlpSenel]

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.

[AlpSenel]

..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.

[jox]

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.)

[pkhamre]

It was correct at the time of the answer.

[Laurent DECLERCQ a.k.a Nuxwin]

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.

[Congmin]

@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.

[pzrq]

Fascinating discussion. At it's core is Apache vs Nginx. Nginx says: nginx.com/blog/nginx-vs-apache-our-view

[pzrq]

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): news.netcraft.com/archives/2018/01/19/…

[pzrq]

Ubuntu is about equal with CentOS (i.e. free Red Hat Enterprise Linux): similartech.com/compare/centos-vs-ubuntu

[pzrq]

A wildcard is Amazon Linux is based on Red Hat and CentOS, exratione.com/2014/08/do-not-use-amazon-linux and Google Cloud Platform seems to have a preference for Debian (Ubuntu), cloud.google.com/compute/docs/quickstart-linux and Azure supports both families. docs.microsoft.com/en-us/azure/virtual-machines/linux/…

[pzrq]

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]

There's also a vim vs emacs vs nano vs <insert text editor of choice> undercurrent lurking here... I'm not sure what to make of that.

[pzrq]

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 =)

[Congmin]

@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.

[pzrq]

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 =)

[Luc]

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...

[Handsome Nerd]

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

[Michael Hampton]

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.