O que está acontecendo?
Você deve estar usando Debian ou Ubuntu, pois o evil sites-available / sites-enabledlogic não é usado pelo pacote upstream do nginx em http://nginx.org/packages/ .
Em ambos os casos, ambos são implementados como uma convenção de configuração com a ajuda da includediretiva padrão no /etc/nginx/nginx.conf.
Aqui está um trecho de /etc/nginx/nginx.confum pacote oficial upstream do nginx do nginx.org:
http {
…
include /etc/nginx/conf.d/*.conf;
}
Aqui está um trecho /etc/nginx/nginx.confdo Debian / Ubuntu :
http {
…
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Portanto, do ponto de vista do NGINX, a única diferença seria que os arquivos conf.dserão processados mais cedo e, como tal, se você tiver configurações que conflitam silenciosamente entre si, as de conf.dpodem ter precedência sobre as do Windows sites-enabled.
As melhores práticas são conf.d.
Você deve estar usando /etc/nginx/conf.d, pois essa é uma convenção padrão e deve funcionar em qualquer lugar.
Se você precisar desativar um site, basta renomear o nome do arquivo para não ter mais um .confsufixo, muito fácil, direto e à prova de erros:
sudo mv -i /etc/nginx/conf.d/default.conf{,.off}
Ou o contrário para ativar um site:
sudo mv -i /etc/nginx/conf.d/example.com.conf{.disabled,}
Evite sites-availablee a sites-enabledtodo custo.
Não vejo absolutamente nenhuma razão para usar sites-available/ sites-enabled:
Algumas pessoas mencionaram nginx_ensitee nginx_dissitescripts - os nomes desses scripts são ainda piores que o restante deste desastre - mas esses scripts também não são encontrados em nenhum lugar - eles estão ausentes no nginxpacote, mesmo no Debian (e provavelmente no Ubuntu também) , e também não está presente em um pacote, você realmente precisa de um script de terceiros não padrão para mover e / ou vincular os arquivos entre os dois diretórios ?!
E se você não estiver usando os scripts (que é, de fato, uma escolha inteligente, conforme mencionado acima), surge a questão de como você gerencia os sites:
- Você cria links simbólicos de
sites-availablepara sites-enabled?
- Copiar os arquivos?
- Mover os arquivos?
- Edite os arquivos no local
sites-enabled?
O exposto acima pode parecer alguns problemas menores a serem resolvidos, até que várias pessoas comecem a gerenciar o sistema ou até que você tome uma decisão rápida, apenas para esquecê-lo meses ou anos depois da linha…
O que nos leva a:
É seguro remover um arquivo sites-enabled? É um link suave? Um link rígido? Ou a única cópia da configuração? Um excelente exemplo de configuração infernal.
Quais sites foram desativados? (Com conf.d, basta fazer uma inversão de busca por arquivos que não terminem com .conf- find /etc/nginx/conf.d -not -name "*.conf"ou use grep -v.)
Não apenas todas as opções acima, mas também observe a includediretiva específica usada pelo Debian / Ubuntu - /etc/nginx/sites-enabled/*- nenhum sufixo de nome de arquivo é especificado sites-enabled, ao contrário de conf.d.
- O que isso significa é que, se um dia você decidir editar rapidamente um ou dois arquivos
/etc/nginx/sites-enablede emacscriar um arquivo de backup como default~, então, de repente, você terá os dois defaulte os default~incluirá como configuração ativa, que, dependendo das diretrizes usadas, pode nem fornecer quaisquer avisos e causar uma sessão de depuração prolongada. (Sim, aconteceu comigo; foi durante um hackathon e fiquei totalmente intrigado com o motivo de minha confissão não estar funcionando.)
Assim, estou convencido de que sites-enabledé puro mal!
www-dataé um tópico separado. A maioria dos sistemas operacionais define um usuário separado com permissões mais baixas que o processo pode executar após a ligação à porta 80 como raiz. É definido no arquivo de configuração. Aplique práticas básicas de segurança a partir daí; não permita que o usuário grave nada em que o servidor da web não precise gravar, não permita que outros usuários gravem nos arquivos, a menos que seja deliberado.