Je dispose d'un ordinateur portable depuis début 2007, ce qui n'est pas si vieux, et quand on regarde sa config matérielle : Intel double coeur à 2GHz, 3GB de mémoire, on se conforte dans l'idée qu'il est loin d'être un ordinosaure.

Et pourtant depuis 2007 j'ai tourné sur beaucoup de distributions Linux, une des premières était debian etch, en version testing si je me rappelle bien. J'étais Pro-Gnome convaincu, et si on en était resté à la version 2 je le serais encore aujourd'hui. A l'époque je râlais quand le système, en 64 bits, consommait 700MB de mémoire, je trouvais que c'était beaucoup. Aujourd'hui je réalise à quel point les OS sont devenus lourds, puisque 700 correspond à ce qui est utilisé à froid au démarrage, et la charge peut gonfler l'utilisation jusqu'à 1,5GB.

Je me rends compte que mon ordinateur est quasiment obsolète au bout de 4 ans, alors que mon utilisation majoritairement bureautique et loisirs n'a pas changé. Pourquoi pouvais-je jouir d'un bureau fluide avec Gnome 2 et Compiz il y a longtemps, et pourquoi ça rame maintenant sur KDE sans même activer les effets ?

Le constat est le même sur mon shitop, nom que j'ai donné à mon netbook Poulsbo, puisqu'il est impossible d'y caser une distribution Linux qui ne rame pas, le seul OS adapté étant visiblement Windows 7 Starter. On a beaucoup critiqué cet OS pour ses limitations, mais en terme de performances sur du matériel faible, il est excellent.

Mon inquiétude se situe justement dans le fait qu'on peut dire que Windows est plus léger que "Linux", à moins de s'amuser à configurer du Openbox et des logiciels allégés ce qui n'est pas vraiment ma tasse de thé. J'aime, et je pense que c'est le cas de beaucoup d'utilisateurs, avoir un système prêt à l'emploi, sur lequel tout est correctement intégré. Si je dois renouveler mon matériel tous les 5 ans pour faire de la bureautique les choses vont commencer à coincer.

Il y a quelques temps j'installais fetchmail sur mon serveur OpenBSD et utilisais la méthode cron pour rapatrier régulièrement du courrier présent sur d'autres serveurs mail. Mais hier je me suis rendu compte que cette méthode n'était pas très propre car elle générait des logs envahissants assez rapidement.

J'ai donc cherché comment faire fonctionner fetchmail de manière autonome, en daemon, sans besoin de passer par cron. Voici la méthode :

Supprimer notre planification cron

$ crontab -e

Retirer le @hourly fetchmail

Créer un script rc.d

# vi /etc/rc.d/fetchmail

Mettre :

#!/bin/sh
#
# $OpenBSD: $

daemon="/usr/local/bin/fetchmail -d 3600"
daemon_user="freeman"

. /etc/rc.d/rc.subr

rc_cmd $1

Attention : fetchmail sera lancé avec les droits de l'utilisateur "freeman", car c'est celui-là qui a tous les paramètres des comptes mail à rapatrier. Adaptez le script à votre situation. 3600 est la période de vérification des messages, exprimée en secondes. Donc là c'est 1 heure.

Essai :

# pkill fetchmail
# /etc/rc.d/fetchmail start
fetchmail(ok)
# ps aux | grep fetchmail
freeman    527  0.4  0.6   852  1620 ??  Ss    10:51AM    0:00.04 /usr/local/bin/fetchmail -d 3600

Ajoutez ensuite fetchmail dans votre rc.conf pour qu'il soit lancé au démarrage.

Ce matin en jetant par hasard un œil dans les logs de smtpd, j'ai vu que beaucoup de messages étaient adressés à un utilisateur dont je me sers uniquement pour les connexions SSH, il n'est pas censé recevoir du courrier. Au début je me suis dit que c'était peut-être le courrier de root, mais non il est déjà redirigé vers un autre.

J'ai donc configuré ce compte dans thunderbird pour pouvoir lire les mails. Et il y en avait 2177 : wtf ? Et finalement c'étaient des rapports d'exécution de tâches cron. Et il faut savoir que j'ai mis une tâche "@hourly" (toutes les heures) pour lancer fetchmail. Donc pour le moment j'ai ajouté un alias de messagerie, pour que cet utilisateur ne reçoive plus rien, et que ce soit un autre qui puisse avoir les rapports.

A terme je pense désactiver ces rapports car ils ne font que mentionner si fetchmail a trouvé du courrier ou non sur les comptes qu'il vérifie... ce n'est pas forcément utile.

Voici une petite présentation de mon serveur de téléchargement autonome accessible par interface web (uniquement depuis le réseau local) qui me sert à télécharger et partager des fichiers sur internet.

Matériel et Logiciel

Le serveur est virtualisé par VMware sur mon ordinateur de bureau, il accède au Core i7 860, et a droit à 256Mo de mémoire vive sur les 8GB disponibles. Le disque virtuel fait 10GB (tout est stocké sur un partage NFS ensuite).

• OS : Debian Squeeze 6.0 amd64
• Client bitorrent / magnet : transmission-daemon
• VPN : OpenVPN + Psilo.fr

Configuration

Stockage

Debian est installé sur le disque virtuel VMware de 10GB, en revanche sur /srv/Torrent j'ai monté un partage nfs, avec l'entrée /etc/fstab suivante :

192.168.10.50:/srv/Torrent/     /srv/Torrent/   nfs     defaults,user,auto,noatime,intr 0 0

Transmission

J'ai modifié les deux paramètres suivants dans /etc/transmission/settings.json :

"download-dir": "/srv/Torrent",
"rpc-whitelist": "127.0.0.1,192.168.10.*,192.168.1.*",

Ceci afin d'autoriser l'accès au WebUI depuis mes deux réseaux, et définir le bon répertoire de stockage des fichiers. Note : vous devez arrêter le daemon transmission avant de faire ces changements, sinon ils seront perdus.

OpenVPN

Il suffit de coller dans /etc/openvpn les fichiers fournis par le prestataire du vpn. Pour ma part j'ai renommé le fichier de configuration en "psilo.conf" pour être certain qu'il soit pris en compte.

Accès à l'interface

Dans un navigateur web, entrez l'IP du serveur suivi du port 9091. Un utilisateur et mot de passe seront demandés : transmission / transmission.

Cliquez sur "Open" pour pouvoir envoyer votre fichier .torrent ou directement coller l'URL. Même procédure avec les magnets. Après quelques secondes le téléchargement devrait débuter.

Astuces

Error: No data found! Au démarrage

Au démarrage du serveur, il se peut que tous les fichiers soient en gris avec l'indication "Error: No data found! Reconnect any disconnected drives, use "Set Location", or restart the torrent to re-download". Il faut aller faire un clic droit sur chaque fichier et sélectionner "Verify Local Data". Mais cela peut être pénible quand il y en a beaucoup, aussi on peut utiliser une commande :

# transmission-remote -n transmission:transmission --torrent all --verify

Cette erreur est probablement due au fait que transmission se lance avant le montage NFS. Il y a probablement des solutions plus propres, je suis preneur ! En attendant, la commande que je donne peut être mise dans un script.

Déconnexion du VPN

Un VPN est tout sauf fiable, il arrive très fréquemment que la connexion soit perdue, ce qui a pour conséquence de faire passer les téléchargements en clair sur internet... et sur transmission il semble impossible de forcer l'utilisation de l'interface tun0. Des manipulations sont sans doute possibles avec SELinux ou Apparmor, mais beaucoup trop complexes pour ce que l'on veut faire.

Alors, avec mon ami Etenil, nous avons concocté un petit bidouillage sous forme de script :

#!/bin/sh

if [ ! -e /sys/devices/virtual/net/tun0 ]
then
        transmission-remote -n transmission:transmission --torrent all --stop
        mail -s "VPN down" xavier@domaine.org
fi

Grossomodo, le script vérifie la présence du fichier tun0, qui est là si le VPN est connecté. Si ce n'est pas le cas, il arrête tous les téléchargements, et envoie une alerte par mail. Ce script est à placer en tâche cron afin qu'il s'exécute régulièrement. Personnellement je lui demande de se lancer toutes les minutes... mais attention, si votre VPN est déconnecté pendant 1 heure, toutes les minutes le script enverra un mail... vous vous retrouverez donc avec 60 mails !

La aussi une solution plus propre est sans doute possible.

Récupérer les fichiers téléchargés

Vous pouvez le faire en installant openssh-server, et en vous connectant en sftp via nautilus, dolphin, filezilla ou autre. Vous pouvez aussi vous amuser à configurer un partage samba ou un accès ftp. Les possibilités sont nombreuses.

Après le buzz sur la montée en flèche de Linux Mint au détriment de Ubuntu, difficile d'ignorer la réputation désastreuse de Unity, la nouvelle interface développée par Canonical. Il y a plusieurs raisons pour ne pas aimer une interface selon moi, j'en ai retenu 4 :

• Ce n'est pas mature : ça plante, c'est lent, les applications ne sont pas intégrées... il faut donc revenir plus tard. C'était le cas avec les premières versions de KDE 4.
• Je ne suis pas d'accord avec les choix ergonomiques qui ont été faits : en gros ça ne convient pas à mon usage ou mes habitudes. C'est mon cas vis à vis de Gnome-Shell.
• Les gens sont stupides et trop bornés pour accepter de changer leurs habitudes : ah pardon, ce n'est pas une vraie raison mais une excuse employée par les développeurs et pas mal de blogueurs.
• Parce saymal : il y a 3 lignes de code proprio ou un des développeurs a dit un gros mot sur la mailing list, il faut donc boycotter. No comment.

Pour ma part mon expérience avec Unity c'était tout d'abord la première solution : elle ne fonctionnait pas sur mon ordinateur, je m'étais donc rabattu sur Kubuntu. Mais récemment j'ai récupéré une iso daily live de Ubuntu 12.04 (actuellement en alpha) pour retenter ma chance.

Et je ne comprends pas pourquoi on s'acharne autant sur Unity, certes c'est différent, mais bien loin d'être aussi déroutant que Gnome-Shell qui est par exemple incapable de se dépêtrer si on a plusieurs fenêtres de Gajim. Là sur Unity c'est possible, la liste des fenêtres actives est maintenant intégrée dans les lanceurs sur la gauche, à la manière du Dock d'OSX pour ceux qui aiment les gros mots. La barre de menu des applications apparait tout en haut de l'écran, là encore comme sur l'OS d'Apple.

Le lancement des applications peut aussi se faire en tapant le nom de ce qu'on veut, par exemple le fait d'entrer "pid" proposera Pidgin (il suffit de valider au clavier ou à la souris). C'est un comportement similaire à KDE (avec alt+f2) ou les autres environnements qui ont des systèmes similaires à Gnome-Do ou Synapse.

Unity 3D fonctionne plutôt bien sur mon ATI X1400, preuve que ça doit être pas trop mal codé. Par contre si vous prévoyez d'utiliser des applications comme Wine, qui ont besoin d'accélération graphique, privilégiez Unity 2D la différence sera flagrante (se règle sur l'écran de login).

Je conçois qu'on puisse ne pas aimer Unity, pour ses simplifications et son orientation "Apple", mais je ne comprends pas pourquoi on en fait tout un buzz et pourquoi Gnome-Shell récolte majoritairement des félicitations alors qu'il casse lui aussi toutes les habitudes des gens et simplifie (souvent trop) le bureau. La réponse selon moi est la 4e de ce que je listais en haut, Canonical saymal, alors que Gnome c'est artisanal, c'est libre, c'est communautaire et pas une vilaine entreprise capitaliste, donc c'est bien.

J'ai gardé pour le moment Unity sur mon ordinateur, car je n'ai pas de problème avec, et aussi car le mode 2D me permet d'avoir de meilleures performances sur Wine+KOTOR qu'avec KDE. Il y a bien entendu des choses que je n'aime pas, comme Empathy le logiciel qui ressemble à une version alpha depuis des années, ou des défauts de jeunesse comme le "panneau de configuration" qui n'a pas de bouton précédent lorsque l'on navigue dans les différentes options.

Au passage j'ai découvert la logithèque ubuntu, que je ne connaissais pas car j'utilise toujours apt-get pour gérer mes logiciels. Quelle surprise de constater que cela ressemble au market android, avec des applications notées par les utilisateurs à l'aide de petites étoiles, des classements par nouveauté, etc. Là encore on peut critiquer ce point, mais selon moi c'est une excellente idée lorsqu'on vise le grand public. La description est complète, il n'y a pas de nom bizarre de paquet, et il suffit d'un clic.

En conclusion je dirais que mon retour sur "ubuntu de base" s'est plutôt bien déroulé, je n'ai pas encore eu de surprise négative pour le moment, et je pense que les choix de Canonical sont les bons pour atteindre son objectif qui est simplifier l'expérience utilisateur, s'aligner sur ce qui se fait ailleurs.