Configuration de subversion et lancement automatique

Depuis quelques temps, j’ai pris l’habitude de gérer mes projets de développement à l’aide d’un gestionnaire de versions, en l’occurrence, subversion. Je n’ai encore jamais eu l’occasion de tester git donc ce choix est simplement basé sur mes préférences actuelles et elles peuvent être amenées à changer. J’utilise subversion car il est libre, facile à mettre en place, agréable à utiliser et surtout, je sais m’en servir.

On peut installer subversion assez simplement soit en passant par les dépôts de paquets des différentes distributions, soit en le compilant soit même (ayant eu besoin de la version 1.7.4 récemment et vu que la version disponible sous xubuntu était la 1.6.17, j’ai été amené à le faire sur mon poste client et cela se fait sans encombre) en installant préalablement ses dépendances (pour ma part zlib, apr et sqlite).

La première chose à faire lorsque subversion est installé est de créer le dépôt qui accueillera le projet. Pour ma part, j’ai créé un dossier /home/SVN dans lequel je créé chacun de mes dépôts à l’aide de la commande :

svnadmin create <nom_du_depot>

Nous allons maintenant configurer le dépôt pour rajouter des utilisateurs et gérer les droits sur les différents dépôts. Pour ce faire, nous allons nous rendre dans le dossier du dépôt, puis dans conf. Dans ce dossier, il y a 3 fichiers qui sont authz, passwd et svnserve.conf. Nous allons tout d’abord modifier le fichier passwd pour rajouter à la fin de nouveaux utilisateurs en suivant ce format :

login = motdepasse

Une fois les utilisateurs et leurs mots de passes ajoutés, nous allons modifier le fichier svnserve.conf. A part lorsque je ne souhaite pas que qui que ce soit puisse lire mon code source si il n’est pas authentifié, je dé-commente les lignes

anon-access = read
auth-access = write
password-db = passwd

Ceci a pour effet d’autoriser la lecture lors d’un accès anonyme et l’écriture pour les utilisateurs authentifiés dont les identifiants sont inscrits dans passwd.

Afin de ne pas laisser ces mots de passes qui sont en clair à la vue de tout le monde, je met les droits des 3 fichiers à 0600.

Il ne reste plus qu’à lancer le serveur à l’aide de la commande suivante :

svnserve -d -r <dossier_contenant_les_depots>

Ici, <dossier_contenant_les_depots> est /home/SVN/.

L’un des problèmes de subversion est que cette action est à répéter à chaque démarrage de la machine. Afin de pallier à ce problème, on peut créer un script de lancement et l’exécuter au démarrage de la machine. Voici le script que j’ai créé (ATTENTION : ce script est adapté à la position de mon dossier subversion mais est à adapter en fonction de la localisation de ce dernier) :

#!/bin/sh
#
### BEGIN INIT INFO
# Provides: svnserve
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start and stop svnserve daemon at boot time
# Description: Controls the main subversion server \svnserve\ with /home/svn
### END INIT INFO

ECHO_BIN=/bin/echo

usage()
{
	$ECHO_BIN "Usage : $0 (stop|start|restart)"
}

SVN_stop()
{
	/sbin/start-stop-daemon --stop --exec /usr/local/bin/svnserve
	$ECHO_BIN "[+] Server stopped"
}

SVN_start()
{
	/usr/local/bin/svnserve -d -r /home/svn
	$ECHO_BIN "[+] Server launched on /home/svn"
}

if [ -x /usr/local/bin/svnserve ]
then
	if [ -z $1 ]
	then
		usage
	else
		case $1 in
			stop)
				SVN_stop
			;;
			start)
				SVN_start
			;;
			restart)
				SVN_stop
				SVN_start
			;;
			*)
				usage
				exit 1
		esac
	fi
else
	$ECHO_BIN "Svnserve not installed."
	exit 1
fi

exit 0

Il faut placer ce script dans /etc/init.d/ et bien penser à lui donner les droits 0755. Une fois à sa place, il ne reste plus qu’à l’activer au lancement de la machine en l’ajoutant aux différents /etc/rcx.d/ à l’aide la commande :

update-rc.d <nom du script> defaults

On peut vérifier à ce moment, après un redémarrage de la machine à l’aide de la commande

ps -e | grep svnserve

que tout est fonctionnel. On pourra alors accéder aux dépots en se connectant à :

svn://<nom_de_domaine_ou_IP>/<nom_du_depot>

Bloquer les documents récents sous Linux

Un des problème récurent que je retrouve sur presque toutes les distributions que j’ai pu tester est le stockage des documents récents. Sous Windows, il est possible d’empêcher le stockage des derniers fichiers/documents utilisés en quelques clics depuis le menu de configuration du menu démarrer, alors que sous Linux la configuration est plus compliquée.

Le fichier qui est chargé de stocker la liste des documents récents peut être le fichier

~/.recently-used.xbel
ou
~/.local/share/recently-used.xbel

en fonction de la distribution.

La solution la plus simple et qui a fonctionné sur toutes les distributions que j’ai testé est de supprimer ce fichier puis de le recréer à l’aide de la commande :

touch .recently-used.xbel

On va ensuite changer ses attributs grâce à la commande :

chattr +i <nom_du_fichier>

Ceci va avoir pour effet d’ajouter l’attribut i au fichier recently-used.xbel. Selon la propre documentation de chattr,

A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Ainsi, aucun logiciel ne sera capable d’écrire les derniers fichiers qui ont été utilisés avec lui et le gestionnaire de fichier ne pourra pas les afficher.

En attendant une solution plus propre et surtout prévue par le gestionnaire de fenêtre, cette solution fait son office.

Activer le wifi sur Xubuntu, sur un PC avec une touche de blocage physique

J’ai récupéré un vieux PC portable avec 512Mo de RAM et j’ai décidé d’en faire un PC d’appoint pour les invités qui auraient besoin d’un accès à internet à la maison et qui n’auraient pas amené leur propre ordinateur. J’ai donc installé une distribution Xubuntu dessus, pour divers avantages que je lui trouve, avec tous les logiciels qui vont bien pour une utilisation d’appoint (firefox, vlc, gimp, libreoffice, …). Ce PC est un HP Compaq nx6110 et possède un bouton d’activation/désactivation du Wifi.

Une fois l’installation, avec une connexion câblée, terminée, un problème restait. Le wifi n’était pas activé avec comme source d’erreur un blocage physique. Une petite recherche sur internet m’a permis de trouver comment vérifier cela grâce à la commande :

rfkill list

Celle ci énumère les blocages existant sur les différentes cartes. En effet, ma carte wifi était bloquée physiquement. Un appuie sur le bouton du wifi et le statut avait changé. Je n’ai pas essayé de redémarrer à ce moment là pour savoir si ceci suffisait mais il est fortement possible que oui. J’ai cependant rajouté une étape qui consistait à taper :

rfkill unblock all

Celle ci me permettait de m’assurer qu’aucun blocage n’était maintenu. Après un redémarrage, ma carte était bien reconnue et débloquée mais le pilote n’était pas installé. Afin de savoir lequel installer, j’ai utilisé la commande :

lspci

qui permet de lister tout le matériel disponible dans l’ordinateur dont la carte wifi et ainsi de connaître la marque de celle ci. J’ai pu alors voir que je possédait une broadcom. Il m’a suffit d’installer les pilotes correspondant en l’occurrence :

apt-get install firmware-b43-installer

pour que ma carte wifi soit enfin fonctionnelle.

Une autre solution que j’avais trouvée sur internet mais que je n’ai pas du tout testée consistait à supprimer purement et simplement le fichier /dev/rfkill.

Enlever les memtests de grub

Utilisant Xubuntu comme distribution principale, je me retrouve, comme avec Ubuntu d’ailleurs, avec memtest86+ d’installé par défaut. Or cette option me surcharge inutilement mon menu de boot grub alors que je ne suis amené à l’utiliser qu’une fois de temps en temps ou lors d’un gros crash de la machine dans lequel je soupçonne une défaillance matérielle (autant dire rarement).

Jusqu’ici, je supprimais purement et simplement memtest86+ de ma machine sans plus me poser de question puis j’actualisais mon menu avec grub-mkconfig.

Depuis ma dernière mise à jour de Xubuntu qui m’a réinstallé ce délicieux paquet, j’y ai réfléchis à deux fois et je me suis dit que je pouvais être amené à l’utiliser autrement qu’avec un liveCD (en vacances par exemple) et que ce n’était finalement pas une mauvaise chose de le conserver. Je ne voulais cependant toujorus pa qu’il figure dans mon menu de boot.

La solution s’est révélée simple puisqu’il m’a suffit de créer un dossier dans /etc/grub.d/, que j’ai nommé deactivate, mais le nom importe peu, et d’y mettre tous les scripts de /etc/grub.d/ que l’on ne souhaite plus voir exécuté. En l’occurence 20_memtest86+. Une fois ce petit déplacement fait, il suffit de regénérer son fichier /boot/grub/grub.cfg avec la commande :

grub-mkconfig -o /boot/grub/grub.cfg

pour ne plus voir apparaître cet énervant memtest au démarrage. Pour le réactiver, il me suffit de remettre 20_memtest86+ à sa place d’origine et à refaire la commande si dessus.

Sélection rectangulaire NetBeans

Me mettant au développement Web pour différents projets dont une interface plus conviviale pour http://www.peanut-soft.com/, je suis tombé sur une option que je trouve fantastique et qui est la sélection verticale. Voulant l’avoir sur mon IDE favoris, je me suis lancé à la recherche d’un plugin me permettant de l’activer.

Et bien la bonne nouvelle est que cette option est nativement intégrée à NetBeans depuis sa version 7.1. Donc à part de rares cas où l’emploi de la 6.9 est encore utile, une simple mise à jour suffit à posséder la sélection rectangulaire.

Pour l’utiliser, il suffit de cliquer sur l’icône correspondante au dessus de la zone de texte ou d’utiliser le raccourcis Ctrl + Shift + R.

Installer les drivers de Canon MP490 à partir de paquets théoriquement incompatibles

L’autre jour, j’ai voulu installer mon imprimante Canon MP490. Je me suis donc rendu sur le site du constructeur et j’ai récupéré les drivers Linux. Malheureusement, les drivers qui sont disponibles sont compatibles i386 et aucun n’est disponible pour architecture amd64. Deuxième point problématique, ces drivers requièrent des dépendances qui ne sont pas satisfaites sur ma distribution.

Plutôt que de mettre à jour toutes les librairies une à une, j’ai choisi une solution, certes hasardeuse et pas des plus propres, mais qui en l’occurrence a fait ses preuves.

J’ai commencé par décompresser l’archive cnijfilter-mp490series-3.20-1-i386-deb.tar.gz puis je me suis rendu dans le dossier packages que l’on vient d’extraire.

Je me suis basé sur ce post que j’ai trouvé et j’ai appliqué les commandes suivantes à chacun des deux paquets :

dpkg -x [package].deb common
dpkg --control [package].deb
nano DEBIAN/control
#On enlève purement et simplement la ligne "Dependencies"
cp -a DEBIAN/ common/
dpkb -b common [package].deb
rm -rf DEBIAN/ common/

Une fois cette étape faite, il m’a resté à exécuter le script install.sh en temps que root pour installer les pilotes.

Un problème restait cependant après l’installation de l’imprimante. L’imprimante me marquait une erreur de cups insecure filter. Le problème était juste un problème de propriété et il suffisait de faire un chown et un chgrp à root des fichiers qui ne l’étaient pas dans les dossiers :

/usr/lib/cups/filter/
/usr/lib/cups/backend/

Certes ce n’est pas la méthode la plus propre mais elle a l’avantage de marcher. L’imprimante est maintenant reconnue tant pour imprimer que pour scanner.

ACPI, récupération des codes touche

Dans mon article précédent, traitant de la création d’un .deb, je parle du script que j’avais créé nommé Asus KBBL Control. Le but était de l’utiliser à travers les raccourcis clavier gérés par l’acpi. Pour savoir quel code correspond à une touche pressée (ou à une combinaison de touches) on utilise la commande suivante :

acpi_listen

Il ne faut pas utiliser la dernière partie du code retourné qui ne correspond pas au code de la touche. Cependant, on peut utiliser le reste pour identifier la touche lors de la création de son event.

Asus Keyboard Backlight Control et paquet .deb

Mon ordinateur portable est un Asus G73J. Il est muni d’un rétro-éclairage clavier des plus pratiques. Cependant, les raccourcis de contrôle au clavier ne sont pas fonctionnels sur la plupart des distributions Linux. J’ai donc créé un script qui me permet, à l’aide d’acpi, d’activer ces raccourcis et de contrôler l’intensité du rétro-éclairage et que j’ai nommé Asus KBBL Control (Asus KeyBoard BackLight Control). [EDIT] Il n’est actuellement pas disponible mais reviendra sous peu [/EDIT]

Pour l’installer et le désinstaller plus facilement, j’ai décidé de créer un paquet .deb. Après un peu de recherche, ceci n’est pas difficile et facilite grandement la tâche de maintient d’applications.

Pour ce faire, il suffit de créer un dossier (le nom importe peu). A l’intérieur de ce dossier, il faut créer un paquet nommé DEBIAN. A l’intérieur de ce dossier, on peut mettre plusieurs fichiers dont :

  • preinst : script exécuté avant l’installation
  • postinst : script exécuté après l’installation
  • prerm : script exécuté avant la suppression
  • postrm : script exécuté après la suppression
  • control : Détails du paquet

Un de ces fichiers est obligatoire cependant, c’est le fichier control. C’est à partir de lui que le paquet final est construit (notamment le nom). Pour plus de détail sur sa construction, il suffit de regarder la manpage :

man deb-control

Cette page étant largement détaillée, je n’entrerais pas dans les détails.

Le logiciel que l’on souhaite empaqueter se met à côté du dossier DEBIAN. On va le placer dans le dossier dans lequel il sera installé en considérant ce dossier comme la racine du disque dur. Ainsi, si mon programme doit être installé dans /etc/acpi, je vais créer à côté de DEBIAN un dossier etc dans lequel je créerais un dossier acpi et dans lequel enfin je mettrais mon programme à installer.

Une fois cette petite cuisine effectuée, il ne reste plus qu’à compiler le paquet. Pour cela, on se place un dossier au dessus du dossier qui contient DEBIAN et le logiciel et on tapera la commande :

dpkg-deb --build <NOM DU DOSSIER>

On a un magnifique fichier .deb qui se créé juste à côté de notre dossier source et qu’il ne restera plus qu’à installer avec un :

dpkg -i <NOM DU PAQUET>

Mise en place de Google Analytics

J’aimais bien les statistiques de connexion disponibles sur les blogs hébergés WordPress. J’ai donc cherché à avoir quelque chose de semblable sur mon blog. Pour ce faire, j’ai donc ouvert un compte Google Analytics.

Pour fonctionner, il est nécessaire de copier un bout de code donné par Google sur toutes les pages du site que l’on souhaite observer.

J’ai tout d’abord testé un plugin nommé Google Analytics for WordPress. Après l’avoir un peu tourné dans tous les sens j’ai trouvé que c’était une usine à gaz étant donné que je ne compte pas configurer quoi que ce soit pour l’instant.

J’ai donc décidé de copier à la main le code dans la page header.php. Comme son nom l’indique, elle est insérée en haut de toutes les pages du blog. Une remarque cependant : utilisant le thème WordPress de base, cette page est présente mais tous les thèmes ne l’intègre pas.

Des plugins comme le All in One SEO Pack prennent directement en charge le code à ajouter aux pages et nous évite d’avoir à le faire manuellement. Un espace est prévu pour entrer le tracking ID correspondant.

La dernière configuration que j’ai appliquée à Google Analytics a été de filtrer mon adresse IP afin de ne pas prendre en compte mes visites sur mon blog comme élément de trafic. Pour ce faire, dans les paramètres de compte correspondant à mon profil sur Google Analytics, cliquer sur Admin, puis Filters, New Filter, donner un nom au filtre et choisir exclude, traffic from the IP addresses, that are equal to, puis rentrer l’adresse IP correspondante.

Revision Control, un plugin pratique pour WordPress

Après avoir rédigé quelques articles, je me suis rendu compte d’une option de base de WordPress que je n’ai pas trouvé très pratique. En effet, il conserve de base toutes les révisions d’un même article. La moindre correction orthographique suivie d’un update résultait en l’ajout d’une entrée dans la BDD contenant le nouveau texte de l’article.

Autant cette option peut être intéressante en cas de travail collaboratif, autant lorsque je suis le seul à rédiger des articles et en plus qu’ils sont destinés à n’être relus que par moi, je trouve ça un peu invasif.

J’ai vu qu’il existait plusieurs solutions dont l’ajout dans wp-config.php de la constante :

define('WP_POST_REVISIONS', false);

Le « false » peut être remplacer par un nombre entier qui représentera le nombre de révision que WordPress devra conserver.

Une autre solution, celle que j’ai adoptée, est l’utilisation du plugin Revision Control. Il permet de configurer en 2 clics le nombre de révision de chaque type de page que l’on souhaite conserver.

Si des révisions avaient déjà eu le temps de se mettre en place, on peut les supprimer soit à l’aide du plugin Revision Delete, solution que j’ai choisi, ou alors en tapant directement dans une console MySql :

DELETE FROM wp_posts WHERE post_type = ‘revision’;