☰

Nova instalação do CentOS 7 (Google Compute), não é possível adicionar entradas do VirtualHost em /etc/httpd/conf.d/

tag-icon • tag-icon virtualhost httpd google-compute-engine
Nova instalação do CentOS 7 (Google Compute), não é possível adicionar entradas do VirtualHost em /etc/httpd/conf.d/

Acabei de fazer uma instalação básica e o Apache 2.4 inicializou perfeitamente. Estou migrando de um servidor antigo que executa o Apache 2.2.

Quando coloco um arquivo /etc/httpd/conf.dque contém uma VirtualHostdefinição e reinicio o servidor, ele trava na inicialização. Esta definição de VirtualHost é aquela que uso em meu servidor anterior.

# systemctl restart httpd.service
Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
# systemctl -l status httpd.service
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2017-01-22 03:03:35 UTC; 10s ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 20621 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
  Process: 20620 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
 Main PID: 20620 (code=exited, status=1/FAILURE)

Jan 22 03:03:35 production-frontend-0 systemd[1]: Starting The Apache HTTP Server...
Jan 22 03:03:35 production-frontend-0 systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Jan 22 03:03:35 production-frontend-0 kill[20621]: kill: cannot find process ""
Jan 22 03:03:35 production-frontend-0 systemd[1]: httpd.service: control process exited, code=exited status=1
Jan 22 03:03:35 production-frontend-0 systemd[1]: Failed to start The Apache HTTP Server.
Jan 22 03:03:35 production-frontend-0 systemd[1]: Unit httpd.service entered failed state.
Jan 22 03:03:35 production-frontend-0 systemd[1]: httpd.service failed.
#

Aqui está o conteúdo do arquivo conf (com o nome de domínio alterado):

<VirtualHost *:80>
    ServerName mydomain.com
    ServerAlias www.mydomain.com
    <Directory /home/kenny/domains/mydomain.com/html>
        Options Indexes FollowSymLinks MultiViews ExecCGI Includes
        AllowOverride All
    </Directory>
    DocumentRoot /home/kenny/domains/mydomain.com/html
    CustomLog /home/kenny/domains/mydomain.com/logs/access.log combined
    ErrorLog /home/kenny/domains/mydomain.com/logs/error.log
    ScriptAlias /cgi-bin /home/kenny/domains/mydomain.com/cgi

    RewriteEngine on

    # Does the file exist?
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d 
    RewriteRule ^ http://mydomain.otherdomain.com [R,L]
</VirtualHost>

Eu verifiquei a sintaxe do arquivo:

# httpd -t
Syntax OK
#

Se eu remover o arquivo e reiniciar, o Apache iniciará perfeitamente. Certifiquei-me de que as permissões em meus arquivos correspondam aos arquivos conf existentes:

# ls -l
total 20
-rw-r--r--. 1 root root 2926 Nov 14 18:04 autoindex.conf
-rw-r--r--. 1 root root  366 Nov 14 18:05 README
-rw-r--r--. 1 root root 1252 Nov 14 16:53 userdir.conf
-rw-r--r--. 1 root root  674 Jan 22 03:03 vhost.mydomain.com.conf
-rw-r--r--. 1 root root  824 Nov 14 16:53 welcome.conf
#

Algo mudou no Apache 2.4 que está em conflito com minha definição de VirtualHost?

Existe algum tipo de medida de segurança em uma instância padrão do Google Compute que está rejeitando minha configuração?

Existe alguma opção de configuração que ajustei anos atrás em meu servidor antigo e esqueci que preciso ajustar minha instância do Google Compute? :)

EDITAR:

Encontrei isto no log de erros:

Permission denied: AH00649: could not open transfer log file /home/kenny/domains/mydomain.com/logs/access.log.
AH00015: Unable to open logs

Eu verifiquei httpd.confe diz que o servidor é executado como User:Group apache:apache. Então fiz o seguinte para garantir que o Apache tivesse permissão para gravar esses arquivos de log:

chgrp -R apache /home/kenny/domains
chmod g+w /home/kenny/domains/mydomain.com/logs

Eu ainda tenho o erro. Eu até tentei:

touch /home/kenny/domains/mydomain.com/logs/access.log
chown kenny:apache /home/kenny/domains/mydomain.com/logs/access.log
chmod g+w /home/kenny/domains/mydomain.com/logs/access.log

Ainda me dando o erro. Garanti que o caminho ancestral também seja executável para o Apache.

/home/kenny is owned by kenny:kenny and is 755
/home/kenny/domains is owned by kenny:apache and is 755
/home/kenny/domains/mydomain.com is owned by kenny:apache and is 755
/home/kenny/domains/mydomain.com/logs is owned by kenny:apache and is 775
/home/kenny/domains/mydomain.com/logs/access.log is owned by kenny:apache and is 664

Conteúdo do audit.log:

type=AVC msg=audit(1485115416.525:2112): avc:  denied  { open } for  pid=25759 comm="httpd" path="/home/kenny/domains/mydomain.com/logs/access.log" dev="sda1" ino=36516072 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1485115416.525:2112): arch=c000003e syscall=2 success=no exit=-13 a0=7f6620cd15a8 a1=80441 a2=1b6 a3=ffffff00 items=0 ppid=1 pid=25759 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)
type=SERVICE_START msg=audit(1485115416.567:2113): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=httpd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed

'

Responder1

Você está executando o CentOS 7, que tem o SELinux habilitado por padrão.

Quando você tenta iniciar o Apache, ele tenta carregar arquivos no diretório inicial do usuário, o que não é permitido por padrão.

Você pode permitir que o Apachelerarquivos nos diretórios pessoais dos usuários definindo o booleano apropriado, httpd_read_user_content. Seria uma ideia melhor realocar o conteúdo da web para algum lugar mais apropriado, como abaixo /srv/wwwou /var/www.

No entanto, não existe um booleano SELinux para permitir que o servidor webescreveraos diretórios pessoais dos usuários, o que obviamente é inerentemente perigoso. Você realmente deveria mover os arquivos de log para outro lugar. A localização padrão é /var/log/httpd. Se os usuários precisarem lê-los, você poderá definir permissões para que eles façam isso.

informação relacionada