Usando / var ou / srv para dados e logs do Apache?

1

Eu sempre configurei o Apache assim:

/etc/httpd/conf/httpd.conf (configuração principal do Apache)

<Directory />
   Options None
   AllowOverride None
   Order deny,allow
   Deny from all 
</Directory>


<Directory "/var/www/html">
    Options None
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

Configuração do Virtualhosts

<VirtualHost *:80>
        ServerName xxxxx.co.uk
        ServerAlias xxxxx.co.uk xxxxx
        DocumentRoot /var/www/html/xxxxx.co.uk   
        ErrorLog /var/www/log/xxxxx.co.uk
        <Directory "/var/www/html/xxxxx.co.uk">
                AllowOverride None
                Options -Indexes -FollowSymLinks
                Order Allow,Deny
                Allow from all
        </Directory>
 </VirtualHost>

Tenho notado que algumas pessoas parecem criar uma pasta específica para o conteúdo e os registros da web, por exemplo

/srv/html/xxxxx.co.uk
/srv/log/xxxxx.co.uk

Eu me pergunto se alguém poderia lançar alguma luz sobre o porquê disso? É mais seguro fazer assim? Existem outras razões para mover o conteúdo do conteúdo da web e efetuar o logout do caminho / var / .....?

Agradecemos antecipadamente: -)

    
por leftcase 17.04.2012 / 20:48

4 respostas

5

Além do ponto de Mike sobre a ESF, aqui está essa discussão em um fórum do Ubuntu:

link

O melhor comentário é:

/var is an older convention. It was meant for data that changes over time ("variable data") such as caches, spool, logs, all sorts of housekeeping and administration files, while "user data" would be in home directories, ... but at some point, probably by lack of any other suitable place, /var become also the place to "data" that daemons would serve to other systems and users (such as databases and web pages). Granted, those files would also 'change over time' but I agree there's a difference between a website and a system log.

Debian still defaults to /var for data, but probably most 'old' linuxes do (eg Redhat) and most documentation assumes /var for this sort of stuff as well, although I've seen examples of /srv as data directory in some (less traditional) applications' admin guides.

FWIW, o CentOS 6 tem um diretório / srv, mas está vazio, e o Apache, por exemplo, usa como padrão / var / www para o diretório raiz. Pode-se argumentar que /srv/logs no seu exemplo deve ser colocado corretamente em /var como é habitual, porque os logs não são coisas que são servidas pela sua máquina.

    
por 17.04.2012 / 21:08
5

Meu entendimento é que /var/www tem sido uma prática comum há séculos, e /srv faz parte de um esforço de padronização do sistema de arquivos. /var/www é o passado, e há um período de transição em que a antiga convenção está sendo gradualmente eliminada em favor da nova convenção.

O primeiro passo na transição para muitas distribuições é muitas vezes criar /srv e preenchê-lo com links simbólicos, por exemplo /srv/www - > %código%. Em algum momento no futuro, eu esperaria ver as distribuições revertendo isso, no ponto em que os arquivos viveriam sob /var/www e o link simbólico seria /srv - > %código%. Ainda no futuro, /var/www presumivelmente desapareceria completamente.

    
por 05.10.2012 / 09:36
3

Você pode dar uma olhada no seguinte

link

Eu também uso / srv. É mais disso que eu faço e prefiro isso, por que tipo de coisa.

    
por 17.04.2012 / 20:57
2

Quando você está lidando com aplicativos realmente grandes, geralmente servindo dados dentro de um cluster, você pode usar backends diferentes (RAID, NAS ...) para / srv e / var, com dois benefícios adicionais:

  • Suas políticas de backup, replicação e snapshot podem ser diferentes para / srv (dados reais) e / var (logs, temps ...)

  • Provavelmente, o acesso aos dados em / var é seqüencial, enquanto que o acesso a / srv tende a ser mais aleatório. Você pode colocar / srv em um back-end mais rápido (NAS com grandes caches ou SSDs) e / var em discos locais mais baratos.

Isso pode ser feito misturando seus dados reais dentro de / var, mas desta forma é muito mais claro e fácil de gerenciar.

    
por 13.07.2013 / 14:23