En écrivant l’article "Icônes gratuites", je me suis demandé, comma à chaque fois que j’écris ’icônes’, s’il faut écire ’icônes’ au féminin ou ’icones’ au masculin. Je me suis donc mis à la recherche d’un dictionnaire, et j’ai trouvé le Dictionnaire de l’informatique et d’internet.

Du même coup, j’ai appris dans le Journal officiel du 10 octobre 1998 "Liste des termes, expressions et définitions du vocabulaire de l’informatique", il est précisé que ’icone’, masculin, ne doit pas être utilisé.

Elle provient du fait que, par défaut, python essaie d’encoder les chaînes Unicode en ASCII pour écrire dans un fichier (qui peut être la sortie ou l’erreur standard). Il faut remplacer l’encodage par défaut qui est ’ASCII’ par ’iso-8859-1’.

Ce changement se fait dans le fichier site.py à la racine du répertoire de python.

Sur ma RedHat 9.0, j’ai remplacé la ligne :

encoding = "ascii" # Default value set by PyUnicode_Init()

par celle-ci :

encoding = "iso-8859-1" # Default value set by PyUnicode_Init()

Voir le chapitre 5.4 de Dive into Python

En revanche, si on n’a pas les droits d’administrateur sur la machine, je ne sais pas comment on fait...

Sur une machine que j’administre (Mandrake 10.1), nous avons rencontré un problème que je ne connaissais pas : il était impossible d’uploader des fichiers dans le LMS Ilias ; les fichiers avaient l’air d’exister dans l’application, mais ils apparaissaient comme des répertoires si on essayait de les ouvrir...

Naturellement, la première chose que nous avons regardée a été les droits sur le répertoire /opt/ilias/data dans lequel les fichiers sont sauvegardés. Evidemment, ils étaient bons (sinon, je n’écrirais pas un article tout exprès...)

Un examen un peu plus approfondi a révélé que l’upload ne fonctionnait pas non plus avec d’autres applic PHP (phpMyAdmin en l’occurrence). Le système était donc en cause...

Après un phpinfo(), j’ai découvert que le répertoire temporaire par défaut était celui hérité de l’environnement de root (/root/tmp). Cette variable (en fait 2 variables : $TMP et $TMPDIR) sont affectées dans le script /etc/profile.d/tmpdir.sh qui vérifie le niveau de sécurité (SECURE LEVEL) positionné dans le fichier /etc/sysconfig/msec . Si ce niveau est supérieur ou égal à 2 (le mien était à 4), le répertoire temporaire est ${HOME}/tmp.

Bien sûr je suppose qu’au démarrage du système, lorsque /etc/init.d/httpd est lancé, le shell de root n’est pas initialisé avec le profil (mais je n’en suis pas certain) et que le problème ne se pose peut-être pas...

En tout état de cause, il existe une solution qui consiste à dire en dur à PHP où sauvegarder les fichiers uploadés. Il faut modifier la directive upload_tmp_dir en mettant le chemin du répertoire choisi (en ce qui me concerne, j’ai mis /tmp).

Sablotron

Le module permettant l’utilisation du processeur XSLT Sablotron nécessite certaines manipulations.

  D’abord, il faut que Sablotron soit installé. Ce programme peut être téléchargé ici. La seule méthode que j’ai réussi à faire fonctionner est la compilation à partir des sources. Par ailleurs, Sablotron est écrit en C++ et nécessite donc un compilateur C++ (et le message qui s’affiche si ce compilateur n’est pas affiché est pour le moins sibyllin) ; le rpm correspondant est gcc-c++ .

  Ensuite, dans le répertoire ext/xslt des sources PHP, il faut modifier le fichier config.m4, en supprimant les lignes :

  Lancer la configuration :

$ ./configure --enable-xslt --with-xslt-sablot=/usr/local

  Reprendre la procédure normale décrite dans l’article précédent

PHP propose certaines fonctionnalités sous la forme de modules. Dans les versions précompilées de PHP (par exemple les rpms fournis avec des systèmes Red Hat ou Mandrake), ces modules n’ont pas forcément été inclus dans la distribution. Voici la méthode pour les compiler afin de pouvoir les ajouter.

D’abord, vérifier que le rpm php-devel est installé :

$ rpm -qa |grep php-devel

Un ligne de ce genre :

php-devel-4.2.2-17

doit s’afficher. Si ce n’est pas le cas, c’est que php-devel n’est pas installé ; l’installer en suivant la procédure standard : télécharger le fichier php-devel-version.rpm sur le web (par exemple en utilisant http://rpmfind.net/) ou le prendre sur le cdrom d’installation, puis, en root :

# rpm -i php-devel-version.rpm

Télécharger la version de php qui a été installée par le distributeur (les anciennes distributions de php sont à l’adresse http://www.php.net/releases.php). Pour connaître la version exacte de PHP, créer un fichier dans l’arborescence du web contenant seulement le code suivant :

Puis charger ce fichier depuis un navigateur, en utilisant l’adresse IP du serveur (ou localhost si la connexion est faite depuis le serveur lui-même).

Décompacter le tarball dans un répertoire quelconque :

Se placer dans le répertoire de l’extension désirée (ici, dbase, par exemple) :

$ cd php-version/ext/dbase

Lancer le programme phpize

Préparer la compilation :

$ ./configure

Dans certains cas, il peut être nécessaire d’ajouter des options à cette commande. Pour connaître les options possibles, utiliser la commande [1] :

$ ./configure --help

Lancer la compilation :

$ make

Installer la bibliothèque ainsi créée dans le répertoire des extensions de PHP (dans notre exemple, /usr/lib/php4/) (attention, vous devez être logé en root) :

# cp modules/*.so /usr/lib/php4/

Si vous ne connaissez pas le chemin de ce répertoire, la commande suivante devrait vous permettre de le trouver :

$ grep extension_dir /etc/php.ini

Modifier le fichier de configuration de PHP : il s’agit en général de /etc/php.ini, mais à partir de Red Hat 9, il vaut mieux créer un fichier dans /etc/php.d/ ; ce fichier porte le nom du module à charger, avec une extension .ini (dbase.ini par exemple). Le texte suivant doit être ajouté au fichier php.ini ou au fichier créé dans php.d (toujours avec l’exemple de dbase) :

extension=dbase.so

Relancer apache (en root) :

# /etc/init.d/httpd stop

# /etc/init.d/httpd start

Recharger le fichier d’info créé au début, afin de vérifier que les nouveaux modules ont bien été pris en compte. Si ce n’est pas le cas, le fichier de log /var/log/httpd/error_log devrait donner des informations utiles pour corriger le problème.

Quelques liens sur le TCO (Total Cost of Ownership, coût total de possession).

http://www.computerworld.com/hardwaretopics/hardware/story/0,10801,42717,00.html

Extrait d’un mémoire de licence sur les logiciels libres. Ce document est intéressant, mais il n’est pas très objectif.

Ressources sur le TCO dans l’éducation.

Une des ressources du lien précédent, article de Jamie McKenzie, expert en technologie de l’enseignement.

http://www.techsoup.org/howto/articlepage.cfm ?ArticleId=295&topicid=11

http://geodsoft.com/opinion/server_comp/tco.htm

http://www.salesforce.com/fr/products/tco.jsp

http://h18000.www1.hp.com/tco/models.html

http://h18000.www1.hp.com/tco/snapshottool.html

http://www.theinquirer.net/ ?article=14282

http://www.neocles.fr/services/clientleger/tco.htm