Il riavvio di Apache fa sì che DocumentRoot debba essere una directory, anche se è una directory e non sembrano esserci problemi di privilegi

Question

Ho una domanda quasi novella. Mi aspettavo di trovare il problema mentre scrivevo questa domanda, ma sono ancora bloccato.

Desidero modificare DocumentRoot per apache, ma continuo a ricevere il messaggio di errore "DocumentRoot deve essere una directory".

Situazione:

• Il codice è in esecuzione in una macchina virtuale VMWare 4.0.4 accumulo di 744.019
• La versione di Linux è Scientific Linux rilasciare 6.4 (Carbon)
• La versione di apache è Apache/2.2.15 (Unix) (questa è una yum install con niente di speciale )

Nel httpd.conf

DocumentRoot "/home/stave/www" 

Quando ho riavviato, ottengo il messaggio

Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf: 
DocumentRoot must be a directory 

Le iniziative intraprese finora:

ho assicurato che la directory esiste:

ls -asl /home/stave 
4 drwxrwxrwx. 2 stave stave 4096 Feb 9 09:08 www 
It even has a file in it "index.html", so I am very sure that the directory exists 

Ho pensato che potrebbe b A problema dei privilegi così (questa è una macchina di sviluppo virtuale isolata da internet, e sto facendo il troubleshooting quindi non sono troppo preoccupato per la sicurezza) come potete vedere ho impostato i privilegi su 777.

Ho persino cambiato l'utente che apache sta funzionando come (e ha confermato che il cambiamento ha funzionato con ps) sul pentagramma per garantire che i privilegi non debbano essere un problema.

StackOverflow

ci sono alcune risposte di overflow dello stack, ma la maggior parte di loro dicono "leggere il messaggio di errore. Si dice che la directory in realtà non esiste". Altri sottintendono che potrebbe esserci un taglio finale alla fine che sarebbe male.

Altri siti web

Il più utile che ho trovato è stato this che ha consigliato

Probabilmente ottenuto "DocumentRoot deve essere una directory" errore anche in realtà è una directory a causa di estensioni di SELinux. Eseguire system-config-securitylevel (o system-config-securitylevel) per disabilitare SELinux per httpd o dare i permessi di SELinux a quella directory: chcon -R -t -h httpd_sys_content_t/path/to/directory *

La mia versione di Linux non è Security Enhanced Linux, quindi senza comprenderlo l'ho provato comunque: nessun effetto.

Situazione attuale

ho esaurito le idee per provare, in modo da tutte le domande o consigli diagnostici sarebbe molto apprezzato

Answer 1

Il link che hai postato nella voce "Altri siti" mette in evidenza la causa principale della vostra problema, che è Selinux.

A meno che il server non faccia parte di un ambiente super sicuro, disabilitare semplicemente Selinux.

Su RedHat/CentOS/Scientific Linux questo può essere fatto facilmente modificando/etc/sysconfig/selinux - trovare il parametro "SELinux" e modificare l'opzione "far rispettare" a "disattivato" secondo l'estratto di seguito:

# SELINUX= can take one of these three values: 
#  enforcing - SELinux security policy is enforced. 
#  permissive - SELinux prints warnings instead of enforcing. 
#  disabled - No SELinux policy is loaded. 
SELINUX=disabled 

È probabilmente consigliabile riavviare il server dopo aver apportato questa modifica.

Answer 2

Mi sono imbattuto in questo problema anche oggi ed è stato perché ho spostato la mia DocumentRoot da/var/www/html a/srv/www/html. Come parte delle nostre politiche di sicurezza, non abbiamo la possibilità di disabilitare semplicemente SELinux.

SO la mia correzione, come ho scoperto è stato per modificare il contesto di file SELinux per/srv per abbinare/var. Un compromesso si, ma ancora meglio che disabilitarlo del tutto. A parte questo ... ho fatto in modo che/srv/www e tutte le sottocartelle avessero il httpd_sys_content_t per abbinare le cartelle in/var/www e ora tutto va bene.

Answer 3

Non dovresti disabilitare SELinux.

È necessario impostare httpd_enable_homedirs su on.

yum -y install policycoreutils-python 
setsebool -P httpd_enable_homedirs on 

Answer 4

Questo è fondamentalmente la stessa risposta di David, ma solo un po 'più chiaro, http al servizio directory è impostato male contesto di sicurezza SELinux.

La spiegazione completa per risolvere questo problema è qui, http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server-(or-13-10-Ubuntu-LAMP)

Il mio problema era che ero abitazioni miei siti web all'interno di una directory diversa rispetto al percorso DocumentRoot di/var/www /, così ho dovuto seguire la terza opzione nel link sopra per correggere. Ho impostato lo stesso contesto file della mia/websites/directory in modo che corrisponda a quello di/var/www /. Ciò che era strano è che le versioni precedenti di CentOS 5.5 non dovevano avere SELinux installato/abilitato, perché i miei altri server non avevano alcun problema con questo e quando l'esecuzione di ls -Z al prompt dei comandi mostrava tali cartelle come 'senza etichetta'.

Sto eseguendo CentOS 6.5 su AWS dall'installazione minima del marketplace ufficiale. Così, quando ho eseguito il comando ls -Z sulle mie cartelle, ho visto esattamente ciò che il link sopra mostra come un possibile problema.

L'esecuzione del comando chcon ha corretto il problema!

Basta sostituire html/con la directory che si desidera utilizzare!

chcon -Rv --type = httpd_sys_content_t html/

chcon -Rv --user = system_u html/

Su un lato nota Ho anche dovuto disabilitare iptables per ottenere il lavoro di routing, le impostazioni predefinite stavano servendo pagine vuote.

service iptables stop

Speranza che aiuta chiunque con lo stesso problema.

Answer 5

envirnoment: Linux - il file system di root su un DocumentRoot SSD su un HDD e montato tramite fstab riavvio apache2 dopo l'avvio - nessun problema sembra essere un problema di temporizzazione che Apache è avviato prima che i monti fstab sono stati completati.

Soluzione alternativa: Definire la directory di DocumentRoot sul file system di root con il proprietario, il gruppo e le autorizzazioni corretti. La directory potrebbe essere vuota.

Answer 6

In primo luogo, non vi è alcun motivo per disattivare selinux per risolvere questo problema, basta cambiare il contesto del file selinux.

In secondo luogo, quando si cambia contesto file di SELinux, è necessario impostare una permanente regola per questa strada, in modo tale che quando i nuovi file vengono copiati e/o sostituire i file esistenti, restorecon risolve in realtà il problema, invece di rompere esso, come nel caso in cui si utilizza solo chcon.

Così, per una DocumentRoot symlink'ed (diamo il percorso effettivo completo della directory come '/ media/myDoc' per questo esempio), eseguire questi due comandi:

semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"

restorecon -R /media/myDoc

Nota: il percorso completo è richiesto quando si utilizza semanage in questo modo. Non si risolverà solo il problema, ma non si interromperà più quando si esegue restorecon (o auto-relabel) in futuro.