Elenco all'interno o all'esterno di VirtualHosts?

C'è una differenza tra mettere i tag di directory all'interno o all'esterno di VirtualHosts? Ho trovato un file di configuration che ha diversi VirtualHosts tutti con la stessa etichetta di Directory dentro e la stessa esterna; quindi penso di sbarazzarmi di questa duplicazione, ma non capisco completamente la semantica coinvolta.

  • Il log di connessione di Apache a netcat non riesce
  • Richieste al secondo più lente quando si utilizza nginx per il bilanciamento del carico
  • Come fare l'host non definito andare alla pagina predefinita in host virtuali apache2
  • Virtualhost non funziona su port diversa
  • Apache non invia il client x509 certificato a Tomcat tramite mod_proxy
  • Apache VirtualHost wildcards con IPv6
  • La richiesta POST viene ripetuta con server nginx loadbalanced (stato 499)
  • Apache2 ritorna 404 per le richieste proxy prima di raggiungere WSGI
  • Apache locale in Windows XP non finisce le richieste di pagina
  • Apache RewriteRule e barre (% 2F)
  • Modificare automaticamente iptables basati sui dati del registro Apache per bloccare i client male comportti
  • logrotate non installa Apache per riaprire i registri su Amazon Linux
  • One Solution collect form web for “Elenco all'interno o all'esterno di VirtualHosts?”

    Un <Directory> all'interno di un <VirtualHost> si applica solo ai file all'interno di quella directory quando si accede tramite quel VHost. <Directory> al di fuori di un <VirtualHost> si applica sempre (a less che non sia stato sovrascritto nel <VirtualHost> o altrove, ovviamente).

    Da un punto di vista della sicurezza, puoi discutere entrambe le parti: livelli di accesso AllowOverride all ( AllowOverride all , f.ex.) sono probabilmente più saggi per configurare all'interno di un <VirtualHost>, poiché un'interazione imprevisto tra gli script su un altro VHost potrebbe consentire di lanciare un attacco XSS. Le restrizioni all'accesso ( Deny from all , Allow from 127.0.0.1 ) hanno più senso al di fuori di un <VirtualHost>, nel caso in cui ci sia una backdoor attraverso qualcosa di simile ad un Alias ​​o ScriptAlias ​​di alto livello. E poi si arriva alle possibilità davvero complicate: where un AllowOverride all ciò che AllowOverride all una restrizione di accesso in un .htaccess go, in quanto si potrebbe avere un VHost che ha distriggersto il suo motore di script per motivi di performance o di sicurezza, ma che poi espone un file con informazioni riservate tipicamente protette da .htaccess ?

    Alla fine della giornata, where posizionare <Directory> finisce per essere una combinazione di tre cose, in ordine crescente di importnza:

    1. Politica – se l'azienda mette <Directory> dentro <VirtualHost>, è quasi certamente sbagliato a rovinare la barca.
    2. Leggenda – se hai sei centinaia di VHost, tutti necessitano della stessa <Directory> stanza, probabilmente vale la pena rompere con la politica.
    3. Sicurezza: se c'è un chiaro vantaggio in termini di sicurezza per un approccio o l'altro, allora questa è la scelta giusta, la politica e la leggibilità sono dannati (anche se ti consiglierebbe di documentare il motivo e il modo in cui si è rotto con la politica e prendere misure come l'utilizzo di Include per massimizzare la leggibilità).
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.