Erreur sur la conf HTTPD/mod_ssl
Fermé
b.hamichi
Messages postés
9
Date d'inscription
mercredi 8 octobre 2008
Statut
Membre
Dernière intervention
16 septembre 2016
-
13 sept. 2016 à 13:58
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 14 sept. 2016 à 20:36
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 14 sept. 2016 à 20:36
A voir également:
- Cannot load modules/mod_ssl.so into server
- Erreur 0x80070643 - Guide
- Dans la table des matières de ce document, le chapitre 6 et ses 2 sections n'apparaissent pas. trouvez l'erreur dans la structure du document et corrigez-la. mettez à jour la table des matières. quel est le mot formé par les lettres en majuscules de la table des matières après sa mise à jour ? - Forum Word
- Code erreur f3500-32 ✓ - Forum Bbox Bouygues
- Erreur 10016 epson - Forum Imprimante
- Erreur c2002 western union ✓ - Forum Vos droits sur internet
2 réponses
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
14 sept. 2016 à 08:00
14 sept. 2016 à 08:00
Bonjour,
Le problème est que le module apache ssl est linké avec libssl.so.1.1, or si tu regardes le contenu de /usr/lib64 il n'existe pas. On peut certes espérer que construire un lien symbolique vers /usr/lib64/libssl.so.1.1 vers /usr/lib64/libssl.so.1.1.0 suffise à résoudre le problème mais ce n'est pas une très bonne approche, car à la prochaine mise à jour de ssl tu risques d'avoir à nouveau ces problèmes (voir dernier paragraphe).
Pour moi le vrai problème est plus profond : tu souhaites installer openssl et apache et tu es passé par une installation "locale" (i.e. sans passer par ton gestionnaire de paquets, mais typiquement par une archive). Au lieu de ça tu aurais dû installer apache et openssl via ton gestionnaire de paquet (yum je suppose).
Ce que je te conseille, c'est donc de supprimer ton installation "locale" et d'installer apache et openssl via ton gestionnaire de paquets. L'autre avantage, c'est qu'apache et ssl seront mis à jour avec le reste du système. Une installation locale requiert quand à elle que tu fasses toi-même la mise à jour, et sur des briques logicielles qu'apache ou openssl, ce n'est pas une très bonne idée : il vaut mieux être à jour pour limiter les risques de failles de sécurité. Pour toutes ces raisons, il est toujours mieux (quand c'est possible) de privilégier une installation par paquets.
Enfin, concernant les numéros de version de librairies, tu n'es pas sensé t'en préoccuper. C'est la gestion en arrière boutique de linux des librairies. En gros un programme est linké avec un nom "générique" (mettons libssl.so) ou "un peu moins générique" (mettons libssl.so.1), qui est un lien symbolique qui pointe vers la version courante de la librairie. L'idée est qu'ensuite, lors d'une mise à jour de la librairie, il suffit de corriger ces liens symboliques pour pointer sur la librairie nouvellement déployée. C'est ce que fait ton gestionnaire de paquets (souvent en invoquant la commande
Bonne chance
Le problème est que le module apache ssl est linké avec libssl.so.1.1, or si tu regardes le contenu de /usr/lib64 il n'existe pas. On peut certes espérer que construire un lien symbolique vers /usr/lib64/libssl.so.1.1 vers /usr/lib64/libssl.so.1.1.0 suffise à résoudre le problème mais ce n'est pas une très bonne approche, car à la prochaine mise à jour de ssl tu risques d'avoir à nouveau ces problèmes (voir dernier paragraphe).
Pour moi le vrai problème est plus profond : tu souhaites installer openssl et apache et tu es passé par une installation "locale" (i.e. sans passer par ton gestionnaire de paquets, mais typiquement par une archive). Au lieu de ça tu aurais dû installer apache et openssl via ton gestionnaire de paquet (yum je suppose).
Ce que je te conseille, c'est donc de supprimer ton installation "locale" et d'installer apache et openssl via ton gestionnaire de paquets. L'autre avantage, c'est qu'apache et ssl seront mis à jour avec le reste du système. Une installation locale requiert quand à elle que tu fasses toi-même la mise à jour, et sur des briques logicielles qu'apache ou openssl, ce n'est pas une très bonne idée : il vaut mieux être à jour pour limiter les risques de failles de sécurité. Pour toutes ces raisons, il est toujours mieux (quand c'est possible) de privilégier une installation par paquets.
Enfin, concernant les numéros de version de librairies, tu n'es pas sensé t'en préoccuper. C'est la gestion en arrière boutique de linux des librairies. En gros un programme est linké avec un nom "générique" (mettons libssl.so) ou "un peu moins générique" (mettons libssl.so.1), qui est un lien symbolique qui pointe vers la version courante de la librairie. L'idée est qu'ensuite, lors d'une mise à jour de la librairie, il suffit de corriger ces liens symboliques pour pointer sur la librairie nouvellement déployée. C'est ce que fait ton gestionnaire de paquets (souvent en invoquant la commande
ldconfig). Ce mécanisme permet aussi de faire co-éxister sur le même système plusieurs versions de la librairie. Mais en théorie, tu n'es jamais sensé "bidouiller" les liens symboliques en question. De manière générale d'ailleurs, tu n'es jamais sensé "bidouiller" sous linux.
Bonne chance
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
14 sept. 2016 à 20:36
14 sept. 2016 à 20:36
Le configure d'openssl et apach nécessite des options spéciales qu'on ne peut pas passer en YUM ou je me trompe.
Effectivement, avec des paquets classiques, le logiciel est déjà compilé, donc tu ne peux pas passer d'option de compilation. Mais les flags classiques sont souvent activés, donc à moins d'un besoin exotique, le paquet fait généralement l'affaire (ça vaut le coup de tester avant de se compliquer la vie avec des sources).
Dans ton cas ceci dit, je comprends que tu sois naturellement parti sur des sources, il est possible qu'effectivement les options dont tu as besoin ne soit pas active.
Pourriez-vous s'il vous plait me dire, en utilisant la commande YUM, comment puis je applique ce type de configuration?
Quand les paquets binaires ne font pas l'affaire, paquets sources peuvent parfois être une alternative intermédiaire (le dernier recours étant de passer par une archive avec des sources en les compilant) :
https://superuser.com/questions/751035/is-there-an-option-for-yum-to-compile-from-source-instead-of-installing-pre-comp
Si je reste sur la méthode manuelle, qu'elle est la mise à jour à faire sur apache et openssl après l'installation?
En fait ce sera à toi de recompiler apache et ssl (en suivant les mises à jour publiées sur les sites respectifs) à défaut de te reposer sur le gestionnaire de paquets. Dit autrement, le gestionnaire de paquets connait les paquets déployés, peut être lancé pour récupérer la liste des nouveaux paquets, et donc déterminer un scénario pour migrer vers les paquets à jour.
Un
Le problème est réglé en rajoutant un autre lien (Merci bq mamiemando :)
De rien :)
AH00526: Syntax error on line 92 of /usr/local/apache/httpd-2.4.23/conf/extra/httpd-ssl.conf:
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).
As tu une idée de quoi il parle?
Dans ce genre de situation, ton réflexe doit être de copier coller le message d'erreur dans google si tu ne le comprends pas. Tu tomberas sûrement sur des forums qui abordent déjà le problème et en explique la cause. Bien entendu le cas échéant, demander des précisions est la suite logique ;-)
Dans ton cas c'est visiblement un module apache (socache_shmcb) qui n'est pas installé et activé, comme le montre par exemple :
https://askubuntu.com/questions/365096/how-can-i-get-apache-ssl-to-work-in-13-10-after-upgrade
https://cuiborails.wordpress.com/2014/12/02/apache2-sslsessioncache-shmcb-session-cache-not-supported/
Attention toutefois, il s'agit d'une autre distribution, donc l'organisation des fichiers de configuration peut différer. Mais en gros sous debian et les distributions qui en dérivent, des "bouts" de fichiers de configuration sont exposés dans les répertoires /etc/{mod,sites,conf}-available, et effectivement considérés si le lien symbolique correspondant /etc{mod,sites,conf}-enabled/ pointe dessus. On en déduit que tu dois dans ton cas ajouter les bonnes directives apache pour activer le module.
Chose à savoir, pour que le changement de configuration d'un démon (ici apache2) soit pris en compte, il faut relancer le service (typiquement
Bonne chance
Effectivement, avec des paquets classiques, le logiciel est déjà compilé, donc tu ne peux pas passer d'option de compilation. Mais les flags classiques sont souvent activés, donc à moins d'un besoin exotique, le paquet fait généralement l'affaire (ça vaut le coup de tester avant de se compliquer la vie avec des sources).
Dans ton cas ceci dit, je comprends que tu sois naturellement parti sur des sources, il est possible qu'effectivement les options dont tu as besoin ne soit pas active.
Pourriez-vous s'il vous plait me dire, en utilisant la commande YUM, comment puis je applique ce type de configuration?
Quand les paquets binaires ne font pas l'affaire, paquets sources peuvent parfois être une alternative intermédiaire (le dernier recours étant de passer par une archive avec des sources en les compilant) :
https://superuser.com/questions/751035/is-there-an-option-for-yum-to-compile-from-source-instead-of-installing-pre-comp
Si je reste sur la méthode manuelle, qu'elle est la mise à jour à faire sur apache et openssl après l'installation?
En fait ce sera à toi de recompiler apache et ssl (en suivant les mises à jour publiées sur les sites respectifs) à défaut de te reposer sur le gestionnaire de paquets. Dit autrement, le gestionnaire de paquets connait les paquets déployés, peut être lancé pour récupérer la liste des nouveaux paquets, et donc déterminer un scénario pour migrer vers les paquets à jour.
Un
ldconfigpermet ensuite en théorie de corriger les liens symboliques, mais parfois il faut les créer manuellement comme tu l'as fait quand tu as une erreur de linkage. Bien sur, sous réserve que cela pointe vers une version raisonnablement proche de la librairie attendue par le programme, sinon certains symboles (fonctions offertes par la librairies) peuvent ne pas exister ou être incompatibles.
Le problème est réglé en rajoutant un autre lien (Merci bq mamiemando :)
De rien :)
AH00526: Syntax error on line 92 of /usr/local/apache/httpd-2.4.23/conf/extra/httpd-ssl.conf:
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).
As tu une idée de quoi il parle?
Dans ce genre de situation, ton réflexe doit être de copier coller le message d'erreur dans google si tu ne le comprends pas. Tu tomberas sûrement sur des forums qui abordent déjà le problème et en explique la cause. Bien entendu le cas échéant, demander des précisions est la suite logique ;-)
Dans ton cas c'est visiblement un module apache (socache_shmcb) qui n'est pas installé et activé, comme le montre par exemple :
https://askubuntu.com/questions/365096/how-can-i-get-apache-ssl-to-work-in-13-10-after-upgrade
https://cuiborails.wordpress.com/2014/12/02/apache2-sslsessioncache-shmcb-session-cache-not-supported/
Attention toutefois, il s'agit d'une autre distribution, donc l'organisation des fichiers de configuration peut différer. Mais en gros sous debian et les distributions qui en dérivent, des "bouts" de fichiers de configuration sont exposés dans les répertoires /etc/{mod,sites,conf}-available, et effectivement considérés si le lien symbolique correspondant /etc{mod,sites,conf}-enabled/ pointe dessus. On en déduit que tu dois dans ton cas ajouter les bonnes directives apache pour activer le module.
Chose à savoir, pour que le changement de configuration d'un démon (ici apache2) soit pris en compte, il faut relancer le service (typiquement
/etc/init.d/apache2 restartou
service apache2 restartou
systemctl apache2 restart). Parfois un "reload" suffit.
Bonne chance
14 sept. 2016 à 09:53
Je teins à vous remercie pour ce message très enrichissant (je débute en linux).
J'ai pensé à faire une installation automatique en passant par la commande YUM, mais, pour un besoin particulier qui consiste à mettre en place une authentification forte en utilisant des cartes à puces, il est fortement déconseillé de suivre cette méthode.
Le configure d'openssl et apach nécessite des options spéciales qu'on ne peut pas passer en YUM ou je me trompe:
Openssl:
./config --prefix=/usr/local/openssl/$ASIP_OPENSSL zlib-dynamic shared enable-ec_nistp_64_gcc_128 -DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_SHA512
Apache:
./configure --prefix=/usr/local/apache/$ASIP_HTTPD --enable-ssl --enable-mods-shared=ssl --with-ssl=/usr/local/openssl/$ASIP_OPENSSL
L'installation s'est déroulé en douleur car il a fallut appliquer des patch openssl mais en final avec succès.
Pourriez-vous s'il vous plait me dire, en utilisant la commande YUM, comment puis je applique ce type de configuration?
Si je reste sur la méthode manuelle, qu'elle est la mise à jour à faire sur apache et openssl après l'installation?
En fin, j'ai tenté le lien que vous m'avez recommandé mais le problème persiste toujours:
[root@servname lib64]# ln -s /usr/local/openssl/openssl-1.1.0/lib/libssl.so.1.1 /usr/lib64/libssl.so.1.1.0
[root@servname lib64]# ll libssl*
-rwxr-xr-x 1 root root 276688 Apr 25 14:34 libssl3.so
lrwxrwxrwx 1 root root 16 Sep 13 16:34 libssl.so.10 -> libssl.so.1.0.1e
-rwxr-xr-x 1 root root 449880 May 9 08:10 libssl.so.1.0.1e
lrwxrwxrwx 1 root root 50 Sep 14 07:29 libssl.so.1.1.0 -> /usr/local/openssl/openssl-1.1.0/lib/libssl.so.1.1
.
Je vous remercié par avance pour votre aide.
Bien cordialement
14 sept. 2016 à 10:47
[root@servname lib64]# ln -s /usr/local/openssl/openssl-1.1.0/lib/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1.0
Mais, j'ai encore une erreur lorsque j'applique la commande:
[root@dentoclik lib64]# /usr/local/apache/httpd-2.4.23/bin/apachectl start
AH00526: Syntax error on line 92 of /usr/local/apache/httpd-2.4.23/conf/extra/httpd-ssl.conf:
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).
As tu une idée de quoi il parle?
Bien Cordialement