Commande de site Nginx enable

131

Nous savons tous comment activer un site Web en utilisant Apache sur Linux. Je suis à peu près sûr que nous sommes tous d'accord pour utiliser la commande a2ensite.

Malheureusement, aucune commande équivalente par défaut n’est fournie avec Nginx, mais il est arrivé que j’ai installé un paquet sur Ubuntu qui m’a permis d’activer / désactiver des sites et de les lister.

Le problème est que je ne me souviens pas du nom de ce paquet.

Quelqu'un sait de quoi je parle?

S'il vous plaît dites-moi le nom de ce paquet et le nom de la commande.

Ghassen Telmoudi
la source
5
L'affirmation à propos de a2ensite n'est pas vraie pour CentOS
utilisateur9517

Réponses:

166

Si vous avez installé le nginxpaquet à partir des référentiels Ubuntu, vous aurez deux répertoires.

/etc/nginx/sites-enabledet /etc/nginx/sites-available.

Dans la configuration principale de nginx /etc/nginx/nginx.conf, vous avez la ligne suivante:

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

En résumé, pour répertorier tous les hôtes virtuels disponibles, vous pouvez exécuter la commande suivante:

ls /etc/nginx/sites-available

Pour activer l'un d'entre eux, exécutez la commande suivante:

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

Les scripts fournis avec Apache sont fondamentalement de simples wrappers de shell qui font quelque chose de similaire à ce qui est décrit ci-dessus.

Après avoir lié les fichiers, n'oubliez pas de lancer sudo service nginx reload/service nginx reload

pkhamre
la source
5
Oui, je sais comment utiliser la ligne de commande, merci
Ghassen Telmoudi
23
Alors je ne suis pas sûr de ce que vous demandez vraiment.
Pkhamre
3
N'oubliez pas de recharger le serveur nginx avec: service sudo nginx reload
Ricardo Martins le
16
@pkhamre: Lorsque vous utilisez Apache, vous utilisez deux scripts: a2ensite et a2dissite. Ils créent et suppriment simplement les liens symboliques que vous décrivez. Ils constituent donc un moyen plus rapide d'activer et de désactiver.
Mads Skjern
6
Merci pour les votes constants sur cette ancienne réponse. Si OP acceptait cette réponse, ce serait épique :)
dimanche
69

Il suffit de créer ce script /usr/bin/nginx_modsiteet de le rendre exécutable.

#!/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

Comment ça fonctionne:

Pour lister tous les sites

$ sudo nginx_modsite -l

Pour activer le site "test_website"

$ sudo nginx_modsite -e test_website

Pour désactiver le site "test_website"

$ sudo nginx_modsite -d test_website
Ghassen Telmoudi
la source
Dans la fonction ngx_relaod, j'ai commenté la lecture et fait reload = "y" puisque je lance ceci via cron et que je ne veux pas du tout l'invite. Merci!
Radtek
oui, c'est parfaitement logique, pouvez-vous me dire où avez-vous apporté le changement?
Ghassen Telmoudi
10
Un assez gros script pour envelopper certaines commandes standard d'une ligne.
tobltobs
1
@tobltobs De bons programmeurs écrivent du code, d'excellents programmeurs volent du code :) Cela fait une belle addition à ma collection de scripts d'imagerie de serveur.
Rdev5
5
@GhassenTelmoudi en tant que script que vous continuez de mentionner est un script tiers, qui n'est même pas intégré par les créateurs (ubuntu) dans le package nginx, votre commentaire suggère d'utiliser un script tiers par rapport à une alternative en ligne de commande (une ligne). C’est ainsi que sont créées les vulnérabilités de sécurité et les arbres de dépendance inutilement complexes
scones
32

Faites-vous allusion à nginx_ensiteet nginx_dissite?

Michael Hampton
la source
16
C'est à peine une réponse, est-ce? Ces commandes ne sont pas présentes sur mon installation de nginx, sur Ubuntu installé avec apt-get. Il semble que ce soit juste un script tiers: github.com/perusio/nginx_ensite
Mads Skjern
5
@MadsSkjern S'il s'agit de "à peine une réponse", alors la réponse acceptée ne l'est pas beaucoup non plus!
Michael Hampton
3
Tout d’abord, merci d’avoir répondu :) Et désolé pour mon commentaire, qui peut paraître choquant, alors que je voulais simplement souligner que ce n’était pas très utile pour moi (à ce moment-là) lecteur.
Mads Skjern
25
Vous avez répondu avec deux commandes et une URL, et même sous la forme d'une question. En tant que personne peu expérimentée, votre réponse m'aurait envoyé googler. Peut-être que je trouverais un guide / tutoriel / démonstration utile en 2 minutes, peut-être que je regarderais autour pendant une heure et que je serais toujours confus. Ce qui m'aurait aidé à l'époque était: "Il existe ces outils nginx_ensite et nginx_dissite, il s'agit d'un script tiers, téléchargez-le à partir d'ici, et ils fonctionnent ainsi, exemple, exemple". La réponse de Ghassen est plus élaborée, plus introductive, plus utile. J'espère que vous comprenez ce que je veux dire :)
Mads Skjern
8
@MadsSkjern Eh bien, vous auriez pu cliquer sur le lien. :)
Michael Hampton
4

NGINX

Si vous utilisez l' un des packages en amont officiels de nginx à partir de http://nginx.org/packages/ , la meilleure méthode consiste à naviguer dans le /etc/nginx/conf.drépertoire et à renommer le fichier concerné, qui porte un .confsuffixe différent. désactiver le site:

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

Ou l'inverse pour l'activer:

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

Cela est dû au /etc/nginx/nginx.conffait que la includedirective par défaut contient les instructions suivantes :

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

Debian / Ubuntu

Cependant, si vous utilisez un dérivé de Debian / Ubuntu conf.d, vous pouvez également avoir les répertoires non standard maléfiquessites-available et sites-enabledcertains répertoires, dont certains fichiers peuvent être inclus sans le savoir, sans tenir compte de leur extension:

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

En tant que tel, dans Debian / Ubuntu, vous devrez d’abord déterminer l’emplacement de la configuration du site.

  • Vous pouvez utiliser la commande suivante pour obtenir une liste de tous les sites disponibles en exécutant find(1)pour rechercher tous les fichiers normaux correspondant au masque donné:

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

  • Vous pouvez utiliser la commande suivante pour obtenir une liste de tous les sites activés :

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

Ensuite, pour désactiver / activer les sites sur Debian / Ubuntu:

  • Pour désactiver un site: si la configuration est active conf.d, renommez simplement le fichier pour qu’il n’ait plus de .confsuffixe; ou si dans sites-enabled, déplacez-le sites-enabled.

  • Pour activer un site, le meilleur moyen consiste à le déplacer /etc/nginx/conf.det à le renommer en .confsuffixe.

PS Pourquoi je pense que Debian include /etc/nginx/sites-enabled/*;est diabolique? Essayez d’éditer quelques fichiers dans ce répertoire et de emacscréer les fichiers de sauvegarde (avec le ~suffixe), puis redemandez.

cnst
la source
4
Je voudrais souligner que le problème avec cette réponse réside dans deux hypothèses erronées concernant Debian et ses dérivés: 1) Le but de l' conf.dannuaire est une configuration à l'échelle du serveur comme celle des modules, plugins, gestionnaires fastcgi, etc. et explicitement de ne pas stocker l'hôte. / vhost configurations in et 2) On ne devrait éditer aucun fichier dans sites-enabled serverfault.com/a/825297/86189
Bojan Markovic
@ BojanMarkovic, vous avez tort. Vous ne pouvez pas servir les configurations à l'échelle du serveur dans conf.d, car il est inclus dans le même contexte que le contexte à sites-enabledun httpniveau, les directives module et plugin peuvent donc ne pas s'appliquer. De même, votre hypothèse qu'il ne faut pas éditer de fichiers sites-enabledest simplement un vœu pieux - il n'y a pas d'instructions de ce type dans la distribution, ni dans le répertoire. ont toutes sortes de problèmes, par exemple, stackoverflow.com/q/45852224/1122270 .
cnst
La question que vous avez évoquée n’a absolument aucun lien avec cela. Je me trompe conf.dtel quel, probablement, le mainteneur Debian de Nginx (ou peut-être est-il conservé pour la compatibilité avec l'amont). Ne pas éditer de fichiers sites-enabled, ce n’est pas un voeu pieux, mais le flux de travail supposé sous Apache qu’ils ont essayé d’imiter sur Nginx. Dans apache , il est tout à fait évident en raison de l' existance de a2ensiteet a2dissitescripts. Malheureusement, rien de la sorte n'est fourni pour Nginx, ce qui montre à quel point la qualité de maintenance de ce paquet est basse sur Debian. Les deux manquent de documentation, c'est vrai.
Bojan Markovic
2
..Je vais vous donner ça (les documents manquent cruellement à cet égard). Cependant, vous êtes la première personne à utiliser des serveurs Web sur Debian à qui j'ai été confondue. Juste un simple ls -al sites-enableddans les deux Apache ou Nginx montre que les fichiers existants dans le répertoire sont des liens symboliques de -available, idem pour les modules sous Apache, ainsi fournies a2enmod/ a2dismodscirpts.
Bojan Markovic
1
@pzrq, vous assimilez beaucoup de choses non liées; le disponible / activé n'a rien à voir avec apache ni debian; à défaut de preuve du contraire, il s’agit en fait simplement de quelque chose que certains responsables ont inséré au bon endroit au bon moment, lorsque personne ne le regardait, et il est resté bloqué; il y a peu de raisons de continuer à l'utiliser si vous dépensez déjà les ressources nécessaires à la transition vers nginx, ce qui nécessiterait déjà une réécriture de la configuration pour se débarrasser de .htaccess, par exemple - pourrait également normaliser votre configuration avec tous les nuages ​​et toutes les distributions à l'esprit. , ce qui est assez facile avec conf.dtel quel .
cnst le
1

Une autre méthode consiste simplement à renommer le fichier de configuration du site en quelque chose qui se termine sans .conf

Par exemple sudo mv mysite.conf mysite.conf.disabled

Rechargez ensuite nginx, et vhost reviendra à la valeur par défaut.

Pyrite
la source
c'est toujours agréable d'utiliser la commande nginx_modsite, vous pouvez lister, désactiver, activer le site beaucoup plus facilement et plus rapidement que renommer le fichier à chaque fois @Pyrite
Ghassen Telmoudi
3
@Pyrite Sous Ubuntu 14.04, l'extension n'a pas d'importance, car nginx.conf inclut des sites activés, car include /etc/nginx/sites-enabled/*;il ne comprend que les dir conf*.conf
Bojan Markovic
2
@GhassenTelmoudi en tant que script que vous continuez de mentionner est un script tiers, qui n'est même pas intégré par les créateurs (ubuntu) dans le package nginx, votre commentaire suggère d'utiliser un script tiers par rapport à une alternative en ligne de commande (une ligne). C’est ainsi que sont créées les vulnérabilités de sécurité et les arbres de dépendance inutilement complexes.
Scones
1
@cnst je n'irais pas jusqu'à appeler cela du mal, en particulier leur choix de sites-availableet sites-enabledcomme ils ont du mérite et de l'utilisation. Quelqu'un devrait probablement simplement créer un rapport de bogue sur la véritable ligne incriminée dans nginx conf /etc/nginx/sites-enabled/*.conf;et ils le feront probablement, car c'est probablement un oubli. Mais si vous respectez le flux de travail Debian, vous allez sites-availablequand même éditer des fichiers et créer des liens symboliques avec ceux pour lesquels vous souhaitez activer sites-enabled.
Bojan Markovic
1
@cnst Le pourquoi va de soi, n'est-ce pas? Il vous permet d'activer et de désactiver vhosts sans les supprimer, de manière identique sur apache et nginx. Le fait que vous soyez exclusivement intéressé par nginx n'invalide pas l'intention des responsables Debian de fournir une méthode d'activation / désactivation similaire pour les deux serveurs Web.
Bojan Markovic