☰

Neue CentOS 7-Installation (Google Compute), kann keine VirtualHost-Einträge zu /etc/httpd/conf.d/ hinzufügen.

tag-icon • tag-icon virtualhost httpd google-compute-engine
Neue CentOS 7-Installation (Google Compute), kann keine VirtualHost-Einträge zu /etc/httpd/conf.d/ hinzufügen.

Ich habe gerade eine Basisinstallation durchgeführt und Apache 2.4 startet problemlos. Ich migriere von einem alten Server, auf dem Apache 2.2 läuft.

/etc/httpd/conf.dWenn ich eine Datei mit einer Definition einfüge VirtualHostund den Server neu starte, stürzt er beim Start ab. Diese VirtualHost-Definition verwende ich von meinem vorherigen Server.

# 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.
#

Hier ist der Inhalt der Conf-Datei (mit geändertem Domänennamen):

<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>

Ich habe die Dateisyntax überprüft:

# httpd -t
Syntax OK
#

Wenn ich die Datei lösche und neu starte, startet Apache einwandfrei. Ich habe sichergestellt, dass die Berechtigungen für meine Dateien mit den vorhandenen Conf-Dateien übereinstimmen:

# 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
#

Hat sich in Apache 2.4 etwas geändert, das mit meiner VirtualHost-Definition in Konflikt steht?

Gibt es in einer Standardinstanz von Google Compute, die meine Konfiguration ablehnt, irgendwelche Sicherheitsmaßnahmen?

Gibt es eine Konfigurationsoption, die ich vor Jahren auf meinem alten Server optimiert habe und einfach vergessen habe, dass ich sie auch auf meiner Google Compute-Instanz optimieren muss? :)

BEARBEITEN:

Habe Folgendes im Fehlerprotokoll gefunden:

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

Ich habe nachgeschaut httpd.confund es heißt, dass der Server als Benutzer:Gruppe läuft apache:apache. Also habe ich Folgendes getan, um sicherzustellen, dass Apache die Berechtigung hat, diese Protokolldateien zu schreiben:

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

Ich bekomme immer noch den Fehler. Ich habe sogar Folgendes versucht:

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

Der Fehler tritt immer noch auf. Ich habe sichergestellt, dass der Vorgängerpfad auch für Apache ausführbar ist.

/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

Inhalt des 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

'

Antwort1

Sie verwenden CentOS 7, bei dem SELinux standardmäßig aktiviert ist.

Wenn Sie versuchen, Apache zu starten, versucht es, Dateien in das Home-Verzeichnis eines Benutzers zu laden, was standardmäßig nicht zulässig ist.

Sie können Apache erlauben,lesenDateien in den Home-Verzeichnissen der Benutzer, indem Sie den entsprechenden Booleschen Wert setzen httpd_read_user_content. Es wäre eine bessere Idee, den Webinhalt an einen geeigneteren Ort zu verschieben, beispielsweise unter /srv/wwwoder /var/www.

Es gibt jedoch keinen SELinux-Booleschen Wert, der es dem Webserver ermöglicht,schreibenin Benutzer-Home-Verzeichnisse, was natürlich von Natur aus gefährlich ist. Sie sollten die Protokolldateien wirklich woanders hin verschieben. Der Standardspeicherort ist /var/log/httpd. Wenn Benutzer sie lesen können müssen, können Sie ihnen die entsprechenden Berechtigungen erteilen.

verwandte Informationen