Suite à une mise à jour du serveur, je me suis aperçu que le serveur Tomcat n’était plus lancé.

La commande ps faux me confirmera qu’il ne se trouvait plus dans la liste des processus.

C’est finalement dans le fichier de log /var/log/syslog que se trouve le message d’erreur à propos du chargement de Tomcat :

jsvc.exec[5678]: java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:139)

Une rapide recherche sur le net me conduira à nouveau vers le système de bugtracking de debian toujours aussi réactif !
Référence du ticket sur le système de bugtracking de debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477363

Les informations importantes

Version de tomcat concernée: 5.5.26-1
Debian : Lenny
Package : tomcat5.5

Cause

jsvc ne trouve pas la librairie java commons-logging. (commons-logging-api-1.1.1.jar)

Solution

Ajouter le chemin de la librairie commons-logging dans le CLASSPATH de jsvc dans le script de démarrage de tomcat5 : /etc/init.d/tomcat5.5

Ce qui donne après modification la ligne suivante :

JSVC_CLASSPATH="/usr/share/java/commons-daemon.jar:
$CATALINA_HOME/bin/bootstrap.jar:
$CATALINA_HOME/bin/commons-logging-api.jar"

Merci à Michael Riedel pour ce correctif.
La prochaine version de Tomcat devrait prendre en compte cette modification. Vive la communauté Debian ^^

Un petit article pour relayer l’information sur le problème de sécurité de OpenSSL sous Debian. Si vous suivez l’actualité vous aurez remarqué les nombreuses news sur les sujets ces derniers jours. Etant donné qu’un schéma vaut mieux qu’un long discours et qu’un peu d’humour est toujours le bienvenue je vous laisse savourer ce post.

edit : un nouveau dessin bien sympatique sur le blog de loldebian.

Pour faire court il s’agit d’un problème avec le générateur de nombre aléatoire utilisé par OpenSSH et OpenSSL. Toutes les clés délivrées par ces outils depuis deux ans sont affectées. Ceci rend les outils qui les utilisent vulnérables aux attaques par bruteforce et ce en un temps très court (20 minutes à une heure !).

Malgré le nombre impressionnant de services impactés et de clés à régénérer, ne cédons pas à la panique. Il est temps de passer à l’action. Il y de nombreux articles qui traitent déjà des procédures à suivre et je ne vais donc pas reprendre l’intégralité des informations ici.

Voici donc ma sélection de liens sur le sujet qui vous permettra de vous en sortir :

• Le wiki de debian pour faire un point complet sur la situation
• Branle-bas SSH/SSL sur l’excellent blog de Roland Mas
• Un bon résumé sur Debian Administration

Bonne lecture et bonne chance à tous.

Ce matin, je me suis aperçu que le blog spiroid n’était plus en ligne. En cherchant la cause sur le serveur et en analysant les logs d’erreur d’apache j’ai trouvé la ligne suivante :

[crit] (28) No space left on device: mod_rewrite: could not create rewrite_log_lock Configuration Failed

Je me suis cependant assuré qu’il restait de la place sur le disque dur à l’aide de la commande ‘df‘. Après une rapide recherche sur internet, j’ai trouvé que je n’étais pas le seul avoir ce problème.

Rapport de bug

Le bug a été signalé sur le système de bugtracking de debian : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450831

Les informations importantes :
Version d’apache concernée: 2.2.6-1
Debian : Lenny
Package : apache2-mpm-prefork

Cause

L’origine du problème pourrait venir de l’utilisation des sémaphores par le module rewrite (url rewriting).
On peut supposer qu’il s’agit d’un problème d’allocation mémoire.

Solution

Pas de patchs ni de correctifs ont été proposés pour le moment.

Solution temporaire

Pour débloquer la situation et libérer les ressources, entrez la commande suivante :
ipcs -s | grep www-data | awk ' { print $2 } ' | xargs ipcrm sem

Le problème est bloquant et risque de survenir après la rotation des logs configurée en général pour se produire chaque jour ou chaque semaine en temps normal. On peut ajouter temporairement la commande ci dessus dans les scripts de configuration de logrotate pour l’executer après chaque redémarrage d’apache lors des rotations de log (Non testé !)

A suivre …

EDIT : Corrigé depuis la version 2.2.8
EDIT : La correction du bug est prévue officiellement pour la version 2.2.9-3