Dan Posté 28 Mai 2004 Posté 28 Mai 2004 Bonjour à tous, Pour ceux que l'aventure tente, voici un script de mise à jour pour serveurs dédiés: Apache 1.3.31 mod_ssl 2.8.18 php 4.3.6 Il suffit d'adapter le répertoire source (ici /home/ovh/src) et de lancer le script après l'avoir transféré par ftp sur le serveur (en mode ASCII ) Pensez à vérifier les options de configuration que vous pouvez avoir modifiées. Dan PS: ou lancez la commande suivante sous ssh pour récupérer le patch : wget http://www.webmaster-hub.com/uploads/apache_1.3.31+mod_ss2.8.18+php_4.3.6.sh
Dan Posté 28 Mai 2004 Auteur Posté 28 Mai 2004 Pour fupap, coyote et JPS, leur serveurs sont déjà patchés (et vérifiés) C'est un atout du "support Hub" ... Dan
Fupap Posté 28 Mai 2004 Posté 28 Mai 2004 bonjour dan Encore une fois le support a bien fonctionné, Cette fois, mon serveur a meme été patché avant qu'ovh me previenne Alors maintenant si tu anticipes, que dire merci
Dan Posté 28 Mai 2004 Auteur Posté 28 Mai 2004 On peut dire que j'ai eu le nez creux TITLE:Apache mod_ssl "ssl_util_uuencode_binary()" Buffer Overflow Vulnerability SECUNIA ADVISORY ID: SA11534 VERIFY ADVISORY: http://secunia.com/advisories/11534/ CRITICAL: Moderately critical IMPACT: DoS, System access WHERE: >From remote SOFTWARE: mod_ssl 2.x Apache 1.3.x Apache 2.0.x DESCRIPTION: Georgi Guninski has discovered a vulnerability in mod_ssl, which potentially can be exploited by malicious people to cause a DoS (Denial of Service) or compromise a vulnerable system. The vulnerability is caused due to a boundary error within the "ssl_util_uuencode_binary()" function when handling client certificates. This can potentially be exploited to cause a stack-based buffer overflow by sending a specially crafted client certificate containing an overly long subject DN (more than 6KB). Successful exploitation requires that the "FakeBasicAuth" option is enabled and that the malicious client certificate is issued from a trusted CA (Certificate Authority). SOLUTION: Update to version 2.8.18 for Apache 1.3.31: http://www.modssl.org/source/mod_ssl-2.8.18-1.3.31.tar.gz A fix for the Apache 2.0 branch is available via CVS: http://cvs.apache.org/viewcvs.cgi/httpd-2....engine_kernel.c? r1=1.105&r2=1.106 PROVIDED AND/OR DISCOVERED BY: Georgi Guninski
Dan Posté 31 Mai 2004 Auteur Posté 31 Mai 2004 On est repris sur le forum interne OVH... http://forums.ovh.net/showthread.php?threadid=2132 Un peu de buzz ne fait jamais de mal Dan
Siddartha Posté 31 Mai 2004 Posté 31 Mai 2004 Héhé Dan Tu vas finir par bosser chez eux si ca continue comme çà Pour ma part, le script bloque au premier wget de la nouvelle version d'Apache. Mais le ftp mirroir doit un peu être à bloc si tout le monde maj en ce moment, je réessaierais plus tard.
Nicolas Posté 31 Mai 2004 Posté 31 Mai 2004 Bonjour, N'ayant pas accès au ftp://mir1.ovh.net/ftp.apache.org/dist/httpd/ je suis passé par http://www.apache.org/dist/httpd/#binaries pour télécharger la version 1.3.31. Bravo pour le script
Siddartha Posté 31 Mai 2004 Posté 31 Mai 2004 Bien vu pour l'autre URL, sur le coup j'y ai même pas pensé En tous les cas, Merci Dan ! Mon serveur est à jour et patché et grâce à toi. Linux Apache/1.3.31 (Unix) mod_gzip/1.3.19.1a PHP/4.3.6 mod_ssl/2.8.18 OpenSSL/0.9.6l 31-May-2004 *.*.*.* SARL Ovh Cerise sur le gâteau, aucune erreur pendant les installs .. Big Up
Dan Posté 1 Juin 2004 Auteur Posté 1 Juin 2004 Selon le trafic, les miroirs peuvent ne pas répondre. Il suffit alors de changer les adresses en s'assurant de ne pas se tromper de version. Dan
Dan Posté 2 Juin 2004 Auteur Posté 2 Juin 2004 J'ai changé les serveurs du script, comme mir1 était plutôt paresseux wget http://www.apache.org/dist/httpd/apache_1.3.31.tar.gz -O apache_1.3.31.tar.gz || exit -1# wget ftp://mir1.ovh.net/ftp.apache.org/dist/httpd/apache_1.3.31.tar.gz -O apache_1.3.31.tar.gzwget http://www.modssl.org/source/mod_ssl-2.8.18-1.3.31.tar.gz -O mod_ssl-2.8.18-1.3.31.tar.gz || exit -1wget ftp://ftp.ovh.net/made-in-ovh/maj-ovh/php-4.3.6.tar.gz -O php-4.3.6.tar.gz || exit -1wget ftp://ftp.ovh.net/made-in-ovh/maj-ovh/mod_gzip.c.gz -O mod_gzip.c.gz || exit -1 Dan
valdo Posté 3 Juin 2004 Posté 3 Juin 2004 Dan, juste une question. Pourquoi n'utilises-tu pas les modules DSO d'apache ? C'est embétant que tu configures apache avec PHP d'hardlinké a l'interieur, car quand on veux mettre à jour les configure de PHP on est obligé de recompiler Apache. Ensuite a quoi te sert le modul filepro. Il me semble que cette base de données (si je me trompe pas est peu utilisée, alor spourquoi la rajouter sur PHP. De plus quel est l'intérêt de mettre l'option de postgresql puisque cette base de données ne tourne pas de base sur les serveurs dédiés ? Ensuite au niveau du mod-gzip ce n'est peut-être pas nécessaire. me trompes-je ? Ensuite une suggestion. Pourquoi ne pas faire un script de ce type qui va mettre a jour la libc et gcc, wget ce genre de choses ? Pourquoi ne pas faire un script qui mette a jour openssl, et qui installe proftpd (il me semblqit que proftpd était mieux que ncftpd) avec le support d'ssl ? tu permetsque je te propose une version du script qui fasse avec apxs ? Laurent.
Dan Posté 3 Juin 2004 Auteur Posté 3 Juin 2004 Laurent, Cette version de script est reprise des installations de base des serveurs dédiés OVH... comme tu trouves dans les fichiers de patch permettant le passage des releases. Je n'ai pas la prétention de réinventer la roue, ni celle de donner des scripts qui poseraient problème lors du prochain passage au release suivant d'OVH. C'est une volonté de ne pas forcer les utilisateurs à se faire les mises à jour à la main pour les prochains patches OVH qui m'a fait opter pour ce type d'installation. Sinon, tu as effectivement raison... En ce qui concerne les modules, tous ne sont pas utiles, tels que filepro ou postgress, mais contrairement à ton affirmation pgsql fait bien partie de l'install OVH standard , même si la base elle-même n'est pas installée. Je mentionne aussi dans mon post initial: Pensez à vérifier les options de configuration que vous pouvez avoir modifiées. Mon métier n'est pas non plus de faire le boulot à la place des hébergeurs tels qu'OVH, et ce script n'était qu'une aide pour tous ceux qui attendaient une mise à jour Apache, mod_ssl et php depuis plusieurs semaines. Libre à chacun de l'utiliser ou non. Dan
valdo Posté 3 Juin 2004 Posté 3 Juin 2004 (modifié) Ouais alors je vais mettre en place un système d'options. je vais voir ça en téléchargeant et en modifiant ton script. ce serait sympa d'avoir des options comme --apxs ou --pgsql ou --dom ou --ssl pour modifier le fonctionnement du script. cela permettrait d'avoir un truc du type ton_script_dont_je_me_souviens_plus_le_nom --apxs --ssl qui permettrait d'avoir un feel like assez proche de la commande emerge de gentoo et sa variable USE. Et puis tu penses quoi du choix d'ovh de favoriser l'installation de redhat 7.2 ? je considère RPM comme un mauvais gestionnaire de dépendances, d'autant plus qu'il n'existe pas, de base, de gestionnaire de packages performant sur redhat. Quand j'essaie d'installer quelque chose depuis RPM, celui-ci me réponds tout le temps que openssh est mal installé. n'aurait-il pas été plus judicieux de la part d'ovh d'installer une version récente de redhat en allégeant le noyau et en mettant à jour les packages avec le système apt-get ou urpmi ? Rien en nous empeche de faire nous même les installations à la main, à moins que ovh ne souhaite absolument avoir le contrôle des patchs sur ces serveurs dédiés. cela pose un problème par rapport à OVH si je me fait un script hand-made ? Ensuite il y a un fichier httpd.conf dans / avec des sous domaines. Saurais tu comment ce fichier est mis à jour ? comment apache se rend il compte de sa présence ? Laurent. Modifié 3 Juin 2004 par valdo
Dan Posté 3 Juin 2004 Auteur Posté 3 Juin 2004 Ensuite il y a un fichier httpd.conf dans / avec des sous domaines. Saurais tu comment ce fichier est mis à jour ? comment apache se rend il compte de sa présence ? Valdo, Tu es libre de faire ce que tu veux sur ton dédié, tant qu'un hack de celui-ci n'impacte que tes sites. Tu peux même changer pour une debian ou une suze si ca te chante... Et le fichier /httpd.conf dont tu parles est un lien symbolique vers /usr/local/apache/conf/httpd.conf, pas un "regular file" Dan
Dan Posté 7 Juin 2004 Auteur Posté 7 Juin 2004 Php-4.3.7 est sorti et corrige quelques bugs (une trentaine) dans cette nouvelle version. J'ai donc rajouté un script pour automatiser cette mise à jour. Dispo à : wget http://www.webmaster-hub.com/uploads/apache_1.3.31+mod_ss2.8.18+php_4.3.7.sh Différences par rapport au script précédent: supprimé filepro et pgsql pour alléger le code. Pensez à les rajouter si vous utilisez Filemaker Pro ou Postgres. Dan PS: le Hub est en PHP-4.3.7
valdo Posté 7 Juin 2004 Posté 7 Juin 2004 le musée du maillot de bain aussi. ce script marche parfaitement. laurent.
Siddartha Posté 7 Juin 2004 Posté 7 Juin 2004 C'est déprimant .. ce script marche encore parfaitement On peut même plus bidouiller en fait et c'est la faute à Dan tout ca
valdo Posté 7 Juin 2004 Posté 7 Juin 2004 (modifié) Oh tu sais ne t'en fais pas. je compte bien bidouiller. Il semblerait que chez cineteck ils utilisent MySQL 4 alors que les serveurs dédiés ovh tournent sur du MySQL 3. Cela est un problème, parce que d'après ce que j'ai lu les tables InnoDB serait plus rapides que les tables ISAM. Cela peut être a l'origine des lenteurs du script de Bernhard. Puis j'ai envie aussi de configurer Apache 2+PHP 4+PHP 5 sur un autre port, avec du postgresql, ceci afin de profiter de PL/pgSQL. Donc il y a encore de quoi bidouiller, sachant aussi qu'à chaque fois que Dan se connecte sur notre bécane il fait les compilations avec gcc 3.4, que nous avons installé. Une chose est sure: si nous devions faire confiance à ovh cela poserait problème pour les serveurs dédiés, étant donné leur peu d'empressement à faire des scripts de release. Le problème du serveur dédié, c'est que c'est toi qui le maintient, et c'est pas super facile, vu qu'il est aussi en production. Laurent. Modifié 7 Juin 2004 par valdo
Dan Posté 8 Juin 2004 Auteur Posté 8 Juin 2004 Salut Laurent, Dans le cas de serveurs Web en production, je ne fais les mises à jour que pour pallier aux failles de sécurité ou lorsque la mise à jour apporte une fonctionnalité supplémentaire dont j'ai besoin. Il est évident que la majorité des serveurs dédiés ne nécessitent pas forcément les dernières versions de chacun des exécutables installés, parce qu'on y passerait bien trop de temps. dan
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant