# uname -a - Mot-clé - bug

Un dotclear vous manque et tout est dépeuplé

Mathieu — Sat, 17 Oct 2015 19:24:00 +0200

Aujourd’hui je n’arrivais pas à accéder au panel d’administration de mon Dotclear aujourd’hui. Après avoir rentré le bon mot de passe, La page tournait en boucle pour terminer sur une erreur 500.

Le blog fonctionnait toujours et toutes les autres pages utilisant PHP n’afichaient aucun problème.

Dans les logs Apache, j’avais :

mod_fcgid: read data timeout in 40 seconds
End of script output before headers: index.php
mod_fcgid: process 3114 graceful kill fail, sending SIGKILL

Aucun processus n’était à 100% de CPU, la BDD était au repos, le processus PHP semblait se “figer” au moment d’ouvrir la page d’administration.

Le site de Dotclear était down lui aussi. Coincidence ?

Juste pour voir, j’ai rajouté dans le fichier host de mon serveur la ligne suivante :

127.0.0.1    download.dotclear.org

Après avoir relancé Apache, l’administration s’est mise à fonctionner !

Ce n’était donc pas une coincidence, si Dotclear essaie de recherche ses mises à jour alors que le site download.dotclear.org est en panne (pour des causes naturelles ou non), le panel d’administration reste en attente d’une connexion et on ne peut plus s’y connecter. Évidemment, plus on raffraichit la page, plus on tape sur ce pauvre serveur de Dotclear.

Pour ceux qui n’ont pas accès à leur serveur, vous pouvez changer l’URL de DC_UPDATE_URL dans le fichier inc/prepend.php pour le faire pointer ailleurs, temporairement :

define('DC_UPDATE_URL','http://download.dotclear.org/versions.xml');

N’oubliez pas de le remettre comme avant une fois le site download.dotclear.org réparé, sinon vous n’aurez plus jamais de mises à jour automatiques

Mise à jour : à priori, il y a aussi les flux RSS qui s’affichent sur le côté de l’admin qui sont aussi à désactiver, j’ai fais un gros patch dans le fichier admin/index.php pour finir par faire marcher l’administration :

--- admin/index.php    2015-10-17 19:58:19.873121948 +0200
+++ admin/index.php    2015-10-17 19:58:08.713227238 +0200
@@ -80,6 +80,7 @@
 $favs = $core->favs->getUserFavorites();
 $core->favs->appendDashboardIcons($__dashboard_icons);
 
+/*
 # Check plugins and themes update from repository
 function dc_check_store_update($mod, $url, $img, $icon)
 {
@@ -165,7 +166,7 @@
 }
 
 $core->callBehavior('adminDashboardItems', $core, $__dashboard_items);
-
+*/
 # Dashboard content
 $dashboardContents = '';
 $__dashboard_contents = new ArrayObject(array(new ArrayObject,new ArrayObject));

GetSimple: URL index/something returns 404

Mathieu — Mon, 03 Feb 2014 11:25:00 +0100

Problem

While using GetSimple with FancyURLs (Apache Rewrite), every menu item nested under the home page returned a 404.

The (rewritted) URL of the home page is /index

The sub-pages URLs are rendered as index/something, and triggered a 404 error.

Solution

Disable MultiViews.

MultiViews is an Apache mechanism for automatically switching wich document is sent to the user, based on the Accept header. Because the front controller is named index.php, MultiViews was trying to reach index.php/something instead of (as specified in RewriteRules) index.php?id=index/something.

How to do it

Open the GetSimple .htaccess file, and locate :

Options -Indexes

Change to :

Options -Indexes -MultiViews

Getsimple : exotic char causes website crash

Mathieu — Fri, 15 Mar 2013 08:29:00 +0100

Input sanitizing while editing pages is not efficient in GetSimple, incorrect char such as NULL or EOT corrupt XML files and crashes the CMS :

Warning: simplexml_load_string(): Entity: line 106: parser error : CData section not finished

Here is a patch :

--- admin/inc/basic.php
+++ admin/inc/basic.php
@@ -654,8 +654,15 @@
     } else {
         $text = htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
     }
-    $text = str_replace(chr(12), '', $text);
-    $text = str_replace(chr(3), ' ', $text);
+    $badchars = array();
+    for ($code = 0; $code < 32; $code++) {
+        $badchars[] = chr($code);
+    }
+    unset($badchars[13]);
+    unset($badchars[10]);
+    $text = str_replace($badchars, '', $text);
+    //$text = str_replace(chr(12), '', $text);
+    //$text = str_replace(chr(3), ' ', $text);
     return $text;
 }

Note that it does not fixes the corrupted XML files, it prevents the corrupted files to appear.

Owncloud : could not calculate folder size

Mathieu — Thu, 17 May 2012 21:53:00 +0200

I recently installed Owncloud, and I already had some problems in order to make it run.

I finally managed to make it run, but I ran into an other problem today.

I tried to upload (with SSH, not with the web interface) my music collection that is bigger than 2Go, and I got the following error :

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[22003]: Numeric value out of range: 7 ERREUR:  la valeur Â« 2857678756 Â» est en dehors des limites du type integer' in /home/.../public_html/lib/db.php:527
Stack trace:
#0 /home/.../public_html/lib/db.php(527): PDOStatement->execute(Array)
#1 /home/.../public_html/lib/filestorage/local.php(326): PDOStatementWrapper->execute(Array)
#2 /home/.../public_html/lib/filestorage/local.php(295): OC_Filestorage_Local->calculateFolderSize('mathieu/files/M...')
#3 /home/.../public_html/lib/filestorage/local.php(47): OC_Filestorage_Local->getFolderSize('mathieu/files/M...')
#4 /home/.../public_html/lib/filesystem.php(573): OC_Filestorage_Local->filesize('mathieu/files/M...')
#5 /home/.../public_html/lib/filesystem.php(346): OC_Filesystem::basicOperation('filesize', '/Musique')
#6 /home/.../public_html/lib/files.php(54): OC_Filesystem::filesize('/Musique')
#7 /home/.../public_html/files/index.php(48): OC in /home/.../public_html/lib/db.php on line 527

It seemed that the Owncloud developers haven’t thought about the weird guy who had more than 2Go of Music. I changed the size of the column from integer to bigint in the PostgreSQL database (I had configured Owncloud with PostgreSQL), and the problem vanished :

ALTER TABLE foldersize ALTER size TYPE bigint ;

I hope it will help those who are stuck with this problem. I will also check if the problem is a known bug, and if it is not, I will declare it in the Owncloud bug tracker.

Thinking about it, maybe the “reasonnable” solution would be to change the value to an “unsigned int”, but it will limit the folders size to 4Go, and the problem could appear again.

EDIT : it is a known and fixed bug (in next version) : http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-296

Firefox 4.0 : Addons conflict between TabMixPlus and TabRenamizer

Mathieu — Sat, 02 Apr 2011 20:00:00 +0200

When using both TabMixPlus and TabRenamizer, if you open a new window, every tab opened in the new window will show a “Loading” status for a very long time.

I deactivated TabRenamizer, and now it works.

Firefox Freeze après avoir installé une extension non officielle

Mathieu — Thu, 17 Mar 2011 22:19:00 +0100

Lors de la mise à jour de modules sur mon Firefox (que la mise à jour soit automatique ou non), mon Firefox plantait, partant dans une boucle infinie avec 100% de CPU consommé. En fait l’explication est simple : c’est une boucle infinie provoquée par la recherche d’un certificat racine built-in pour réaliser la mise à jour.

Voir ce bug sur Bugzilla, dont le fix est à l’origine du problème.

Solution : Désinstaller (désactiver ne suffit pas) ces modules. Désolé, pour l’instant je n’ai pas d’autre solution…

Le code coupable en question :

while (issuer && !cert.equals(issuer)) {
cert = issuer;
issuer = cert.issuer;
}