Pourquoi mon Apache ne fonctionne-t-il pas après la mise à niveau vers Ubuntu 14.04?

[aman@aman-Inspiron-1440:~$ apache2
[Mon Apr 21 17:36:38.019213 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_LOCK_DIR} is not defined
[Mon Apr 21 17:36:38.019345 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_PID_FILE} is not defined
[Mon Apr 21 17:36:38.019370 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_RUN_USER} is not defined
[Mon Apr 21 17:36:38.019385 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_RUN_GROUP} is not defined
[Mon Apr 21 17:36:38.019414 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
[Mon Apr 21 17:36:38.028756 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
[Mon Apr 21 17:36:38.029032 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
[Mon Apr 21 17:36:38.029056 2014] [core:warn] [pid 4134] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
AH00526: Syntax error on line 74 of /etc/apache2/apache2.conf:
Invalid Mutex directory in argument file:${APACHE_LOCK_DIR}

Ceci est le contenu du /etc/apache2/apache2.conffichier.

J'ai eu ce problème: la cause est dans le fichier

/etc/apache2/sites-available/000-default.conf 

où la racine a changé:

avant la mise à niveau = /var/www
après la mise à niveau =/var/www/html

Alors éditez pour modifier ce fichier

sudo gedit /etc/apache2/sites-available/000-default.conf

Et redémarrez Apache

sudo service apache2 restart

J'ai eu ce problème même si Apache travaillait pour moi. Je voulais simplement faire un rapide

$ /usr/sbin/apache2 -V

pour trouver la valeur de SERVER_CONFIG_FILE. Parce que ce n'est pas la façon de démarrer apache2, cela échoue avec les erreurs que l'OP poste. Une solution simple et rapide consiste simplement à définir les variables d’envois manquantes en premier:

$ source /etc/apache2/envvars
$ /usr/sbin/apache2 -V

Ceci définit la variable APACHE_LOCK_DIR et tout va bien ( -D SERVER_CONFIG_FILE="apache2.conf").

Symptômes et solution

Dans de nombreux sites Web et forums de questions-réponses, les gens confondent symptômes et causes réelles. Je viens de mettre à niveau un serveur Ubuntu de 13.10 à 14.04.1 et j'ai rencontré exactement les mêmes symptômes que ceux décrits par l'OP, notamment:
1- Apache apparemment ne fonctionne pas. 2- Variable de configuration apache non définie. 3- l'erreur de syntaxe mentionnée par l'OP.

Le problème est que tous ces symptômes ne sont pas réellement liés au problème actuel et qu’ils ne font que distraire ceux qui s’efforcent de les aider.

Différents problèmes à la racine peuvent amener les administrateurs à accéder à des sites tels que celui-ci avec à peu près la même description: "J'ai mis à niveau le système d'exploitation et maintenant, Apache ne fonctionne plus ..."

Une cause spécifique

Ayant tous les mêmes symptômes apparents que le PO, j'ai été attiré par cette question. Malheureusement, la seule réponse qui contenait un indice valable sur la cause réelle de mon problème était un vote négatif (-1), posté par user1469291 avec un représentant de 1 !! J'ai donc cherché d'autres sites Web jusqu'à trouver une explication claire du problème (et donc de la solution).

La solution qui suit ne résoudra peut-être pas le vrai problème du PO, mais je suis certaine que cela aidera d’autres personnes qui pourraient être attirées par cette question pour les mêmes raisons que moi.

/etc/apache2/apache2.conf contient:

# Include generic snippets of statements
IncludeOptional conf-enabled/*.conf

# Include the virtual host configurations:
IncludeOptional sites-enabled/*.conf

ce qui signifie que seuls les fichiers de configuration de site dans / etc / apache2 / sites-enabled / se terminant par .conf seront chargés. Les liens symboliques plus anciens dans ce répertoire seront ignorés.

Auparavant, il s'agissait simplement de sites / *. C'est pourquoi tous mes fichiers de configuration d'hôte virtuel que je nommais simplement ww1.example.com, ww2.example.com, etc. fonctionnaient, mais qui tout à coup et initialement inexplicablement ont cessé de fonctionner après la mise à niveau.

Donc, changez la directive ci-dessus et rechargez Apache, ou, comme je l’ai fait, supprimez manuellement tous les liens symboliques anciens de sites-enabled /, renommez tous les fichiers de sites-available / pour ajouter le suffixe .conf, puis réactivez-les chaque fois. site individuellement.

De plus, la directive par défaut dans apache.conf est plus stricte:

<Directory />
  Options FollowSymLinks
  AllowOverride None
  Require all deny
</Directory>
<Directory /var/www/>
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

Donc, si vous hébergez vos sites virtuels dans / home / user / quelque part, veillez à remplacer la directive de manière appropriée.

En regardant de près votre problème, vous ne faites que courir apache2. Pour démarrer apache sous Ubuntu, exécutez la commande suivante:

sudo apache2ctl start

La configuration d'Apache est divisée en plusieurs fichiers, l'un de ces fichiers étant des variables d'environnement. Lorsque vous exécutez simplement apache2, ces variables ne sont pas définies.

Le script apache2ctl chargera les variables (et fera d’autres tâches si nécessaire) avant de démarrer apache avec apache2 -k start.

Editez la configuration sudo leafpad /etc/apache2/apache2.conf:

# Include the virtual host configurations:

#before upgrade = 
IncludeOptional sites-enabled/*
#after upgrade = 
/IncludeOptional sites-enabled/*.conf

ou supprimer le fichier.

La réponse d'augustin a fonctionné pour moi lorsque tous mes hôtes virtuels ont disparu suite à une mise à niveau du serveur de 12.04 LTS à 14.04 LTS. Je le reviendrais si j'avais la réputation de le faire.

La commande suivante ajoutera le .confsuffixe à tous les liens symboliques /etc/apache2/sites-enabledqui ne l’ont pas déjà:

sudo find /etc/apache2/sites-enabled -type l ! -name '*.conf' -exec rename 's/$/.conf/' {} \;

De plus, l'utilisation de la syntaxe Allow from/ dans le module mod_authz_host a été modifiée ( voici le lien pour la documentation 2.2).Deny fromRequire

La commande suivante éditera l'usage courant de " Order allow, denysuivi de" suivi Allow from allde "être à la Require all grantedplace":

perl -0777 -pi.bak -e 's/Order\s+allow\s*,\s*deny\s*\n\s*Allow\s+from\s+all/Require all granted/sg' /etc/apache2/sites-available/* 

En fait, le docroot change entre précis et fiable de / var / www à / var / www / html. Il est faible que le script do-release-upgrade ne régresse pas le dossier racine.

A) Soit est valide, mais le HTML est plus conventionnel. CentOS est influent à cet égard. La page "ça marche" est plus mature maintenant aussi.

B) Vous n'êtes pas obligé d'utiliser / var / www / html, mais si vous le faites ...

• vous devez migrer votre contenu ou l'alias (non recommandé).
• vous devez mettre à jour n'importe où l'ancien emplacement est référencé.
• en particulier les scripts de sauvegarde / restauration / personnalisation.

C) Et il peut être plus facile de construire à partir de la base et de migrer.

D) Ce symptôme se produira si vous "Sudo Apache2 -k Gracieux" est prêt à l'emploi avec Trusty, que vous effectuez une mise à niveau ou non en raison de l'absence d'envars dans la portée?. Utilisez plutôt "sudo apache2ctl start / stop / restart".

Dans mon cas:

• Le htmlsous-dossier at /var/www/existait déjà mais j'avais quand même l'erreur:AH00526: Syntax error on line 74 of /etc/apache2/apache2.conf
• J'avais déjà décidé d'héberger mes sites Web à la racine de mon utilisateur, par exemple à la /home/{user}/sites/place de l'adresse par défaut./var/www/html
• J'utilise Apache 2.4.7 (vous pouvez vérifier votre version avec apache2 -v)

Comment j'ai résolu le problème en cinq étapes faciles:

1. Dans /etc/apache2/apache2.confj'ajouté , après la ligne 169:

   <Directory /home/{user}/sites/>
       Options Indexes FollowSymLinks
       AllowOverride None
       Require all granted
   </Directory>
   

2. Je me suis assuré que ma configuration d'hôte virtuel nommée website.confà /etc/apache2/sites-availableétait copiée à partir de la configuration par défaut 000-default.confet ressemblait à:

   <VirtualHost *:80>
       ServerAdmin webmaster@localhost
       ServerName website.dev
       ServerAlias www.website.dev
       DocumentRoot /home/{user}/sites/website
   </VirtualHost>
   

3. J'ai rechargé mon site ( sudo a2dissite website && sudo a2ensite website) et mon serveur et l'erreur initiale a disparu. WOOHOO! Mais un nouveau est apparu: "AH00035: accès à / refusé (chemin du système de fichiers '/ home / {utilisateur} / sites') car les autorisations de recherche sont manquantes sur un composant du chemin". J'ai résolu ce problème à l'étape 4.

4. Le nouveau problème était dû aux autorisations, aussi je viens de définir chacun des répertoires menant au websitedossier chmod 755. Chacun! Le homedossier, le dossier {utilisateur}, le dossier de sites et même le dossier de mon site Web

5. Après avoir rafraîchi mon navigateur à website.devtout chargé bien!

PS j'avais déjà configuré website.devdans mon /etc/hostsfichier.

Conseil bonus: pour vérifier les autorisations d'un dossier particulier, vous pouvez utiliser la commande stat -c %a /path/to/file/or/folder. Pour vérifier les autorisations de chaque partie d'un répertoire, utilisez namei -m /path/to/final/folder.