web-dev-qa-db-fra.com

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}

This est le contenu du fichier /etc/Apache2/Apache2.conf.

apache214.04
36
Amandeep Singh

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

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 plus le moyen de démarrer Apache2, il échoue avec les erreurs que l’OP publie. 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").

50
lane

Symptômes et solution

Dans de nombreux sites Web ou 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 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 véritable cause 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 ont soudainement et initialement inexplicablement 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/utilisateur/quelque part, veillez à remplacer la directive de manière appropriée.

14
augustin

En regardant de près votre problème, vous utilisez simplement 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 uniquement Apache2, ces variables ne sont pas définies.

Le script Apache2ctl chargera les variables (et effectuera d'autres tâches si nécessaire) avant de démarrer Apache avec Apache2 -k start.

6
Dan

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.

4
Mauro Leites

augustin's answer a travaillé 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 suffixe .conf à tous les liens symboliques dans /etc/Apache2/sites-enabled qui ne l'ont pas déjà:

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

En outre, l'utilisation de la syntaxe Allow from/Deny from vers Require dans le module mod_authz_Host ( here est le lien de la documentation 2.2).

La commande suivante éditera l'usage courant de Order allow, deny suivi de Allow from all pour devenir Require all granted à la place:

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/*
2
TobyLL

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 "Sudo Apache2 -k Gracieux" est prêt à l'emploi avec Trusty, mis à niveau ou non en raison de l'absence d'envars dans la portée?. Utilisez plutôt "Sudo Apache2ctl start/stop/restart".

1
mckenzm

Dans mon cas:

  • Le sous-dossier html at /var/www/ existait déjà, mais le message d'erreur suivant apparaissait: 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. /home/{user}/sites/ au lieu de la valeur 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.conf j'ai ajouté ce qui suit 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 du 000-default.conf par défaut et ressemblait à ceci:

    <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 étant dû aux autorisations, je viens de définir chacun des répertoires conduisant au dossier website à chmod 755. Chacun! Le dossier home, le dossier {utilisateur}, le dossier de sites et même le dossier de mon site Web

  5. Après avoir actualisé mon navigateur à website.dev, tout s'est bien chargé!

P.S. J'avais déjà configuré website.dev dans mon fichier /etc/hosts.

Bonus Astuce: 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.

0
jhbsk