Apache VirtualDocumentRoot como uma variável

1

Posso usar o documento raiz resultante de um VirtualDocumentRoot como uma variável em outros lugares no mesmo VirtualHost?

Pegue o seguinte VirtualDocumentRoot, por exemplo:

VirtualDocumentRoot "/var/workspaces/%1"

A raiz do documento resultante do nome do host test.localhost é /var/workspaces/test . Que também é visível como o documento raiz no $_SERVER['DOCUMENT_ROOT'] no php.

Então, posso usar o documento real root em uma diretiva PutEnv ou Define na configuração do apache? Existe uma variável na configuração do apache com a raiz do documento atual?

edit:

Eu quero usar isso para alguns casos de uso diferentes.

Eu quero definir um diretório de log para todos os meus aplicativos, então eu quero fazer algo assim:

SetEnv LOG_DIR ${DOCUMENT_ROOT}/logs/

Ou eu quero apontar os aplicativos do php-fpm na direção certa:

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9764${DOCUMENT_ROOT}/$1

Ou defina diretivas diferentes em um subdiretório na raiz do documento:

<Directory "${DOCUMENT_ROOT}/bin">
    
por Leon 16.04.2017 / 14:06

1 resposta

1

Primeiro, gostaria de salientar que o estado desejado de seus casos de uso pode ter alguns problemas de segurança.

Por que você gostaria de armazenar logs dentro de DocumentRoot ? Isso aumenta o risco de expor os registros para público. É claro que você pode evitar isso com uma nova diretiva <Directory> , mas é mais fácil manter os logs em um diretório diferente. Também é mais gerenciável na perspectiva das permissões de diretório, considerando Aviso de segurança de arquivos de log :

Anyone who can write to the directory where Apache httpd is writing a log file can almost certainly gain access to the uid that the server is started as, which is normally root. Do NOT give people write access to the directory the logs are stored in without being aware of the consequences; see the security tips document for details.

In addition, log files may contain information supplied directly by the client, without escaping. Therefore, it is possible for malicious clients to insert control-characters in the log files, so care must be taken in dealing with raw logs.

Por outro lado, não é possível separar o arquivo de log de cada host virtual se estiver usando mod_vhost_alias . Embora a motivação para usar Hospedagem virtual em massa dinamicamente configurada esteja tendo apenas um "curinga" VirtualHost contêiner para todos os customer-*.example.com ,

The main disadvantage is that you cannot have a different log file for each virtual host; however, if you have many virtual hosts, doing this can be a bad idea anyway, because of the number of file descriptors needed. It is better to log to a pipe or a fifo, and arrange for the process at the other end to split up the log files into one per virtual host. One example of such a process can be found in the split-logfile utility.

Parece que neste caso, a configuração precisa atender a esses requisitos :

  • você tem uma quantidade limitada desses "espaços de trabalho"
  • você gostaria de ter exatamente a mesma configuração para cada espaço de trabalho
  • a configuração precisa ser personalizada para suas necessidades especiais
  • você gostaria de facilitar a adição de mais espaços de trabalho sem adicionar novos contêineres VirtualHost .

Assim, considerando todas as limitações com mod_vhost_alias , sugiro abandoná-lo e usar mod_macro em vez , pois atenderia aos requisitos e é muito mais flexível.

Uma macro de exemplo com todos os exemplos da sua pergunta (até mesmo o não recomendado LOG_DIR ):

<Macro Workspace $workspace>
  <VirtualHost *:80>
    ServerName $workspace.localhost
    DocumentRoot "/var/workspaces/$workspace"

    SetEnv LOG_DIR "/var/workspaces/$workspace/logs/"

    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9764/var/workspaces/$workspace/$1

    <Directory "/var/workspaces/$workspace">
      Require all granted
    </Directory>

    <Directory "/var/workspaces/$workspace/logs">
      Require all denied
    </Directory>
  </VirtualHost>
</Macro>

Agora, você pode adicionar todos os espaços de trabalho com:

Use Workspace test
Use Workspace another
Use Workspace third

Ao contrário de mod_vhost_alias , você ainda pode ter um domínio personalizado para cada espaço de trabalho. Apenas modifique <Macro Workspace $workspace $hostname> e ServerName $hostname e você pode usar a macro com Use Workspace testwithdomain example.com .

    
por 18.04.2017 / 11:29

Tags