L'objectif est ici de mettre en place un serveur subversion comprenant la mise en place du dépôt, la configuration d'apache et le paramétrage des messages de notifications.

SSH est un utilitaire absolument vital pour Unix, mais aussi pour Windows. Dans une première approche il permet juste d'ouvrir un terminal à distance et n'est alors pas sans rappeler le vénérable Telnet. Mais à y regarder de plus prés il se révèle sous le jour d'un véritable couteau suisse sécurisé, permettant en vrac de lancer à distance des applications graphiques, de créer des proxy sécurisés, de router tout un trafic IP sur un canal crypté, de lancer des commandes à distances,etc. En somme, outil fondamental qu'il est indispensable de maîtriser.

Difficile de se passer d'un planificateur de tâche, que ce soit pour faire des sauvegardes, vérifier l'intégrité des systèmes, faire le ménage ou bêtement se réveiller le matin. Sous UNIX, le temps c'est le domaine du vénérable CRON.

Peu de monde connaît Sieve présent sur la majorité des serveurs IMAP, dont Dovecot et Cyrus. Pourtant il peut rendre d'immenses services comme trier automatiquement le spam, les publicités, ou même renvoyer un message d'absence lorsque vous êtes en vacance, le tout sans avoir à paramétrer le moindre client.

Lorsque l'on a besoin de créer un environnement de test il est nécessaire que sa composition soit strictement contrôlé (paramétrages, applications et services disponibles et lancées, etc). Il n'est du coup généralement pas conseillé d'utiliser sa machine de travail, sauf si elle ne sert qu'à cela, sous peine d'en détériorer le fonctionnement en cas de test malheureux ou de modifier sans le vouloir le comportement de ce que l'on cherche à tester. Nous sommes alors contraints d'avoir soit une machine virtuelle dédiée aux tests, soit une machine physique supplémentaire.

Ce serait sans compter sur la commande chroot qui permet dans certaines conditions d'obtenir un environnement de test ou d'intégration identique à celui en production, sans machine physique supplémentaire et sans que la machine principale soit ralentie ou compromise.

La problématique peut sembler étrange mais la preuve que cela arrive vu que j'y suis confronté. Je travaille depuis longtemps sur Subversion et pour rien au monde je ne reviendrais sous CVS. D'un autre côté certaines forges (typiquement cette de Drupal.org) sont eux sous CVS. Et vu que je suis une feignasse sans nom, l'idée de m'amuser à synchroniser cela à la main ne m'a pas amusé bien longtemps. Et une fois de plus, bash me sauve la mise

Lorsque l'on dispose de plusieurs machines sur un réseau et que l'on se retrouve dans la nécessité de faire une grosse compilation, il est rageant de ne pouvoir compter que sur le processeur de sa seule bécane. C'est là qu'intervient distcc, un petit outil bien pratique qui permet de distribuer la compilation.

Les langages de Shell, dont Bash n'est que la version GNU, sont de vénérables ancêtres aussi vieux que la ligne de commande elle-même. Le Korn Shell ou ksh par exemple a prés de 30 ans.

Suivant la croyance que tout ce qui est nouveau est mieux, Bash, et ses confrère, est souvent relégué au rang d'antiquité bordélique et peu puissante. Mais lorsqu'il est mieux connu, BASH est en réalité assez cohérent et permet de scripter à une vitesse étonnantes des choses très évoluées pour le nombre de lignes de code produites. Ce n'est pas un hasard si le coeur du démarrage de Linux n'est à peu prés écrit qu'en Bash.

Le but de ce tutoriel n'est pas d'expliquer comment fonctionne BASH. Il y a d'excellent tutoriels qui font cela très bien. Mon idée est plus de documenter dans la langue de Molière certains aspects plus pointus de ce langage et en l'occurrence l'utilisation des blocs de codes, des fonctions et des variables.

S'il y a bien un truc qui fait peur au nouveaux linuxiens, c'est la ligne de commande. Certains la prétendent archaïque mais il s’agit plus d’une crainte liée à une manière "nouvelle" de travailler. En effet, la ligne de commande, comme toutes les interfaces, a ses forces et ses faiblesses. Et chercher à organiser ses fichiers avec est aussi idiot que de systématiquement utiliser une interface graphique pour les décompresser. Ce billet n'est donc pas une ode à la ligne de commande, mais juste une modeste introduction permettant, je l’espère, de prendre conscience de sa puissance pour un certain nombre de tâches spécifiques.

Contrairement aux idées reçues, une fois lancé, une application Java se comporte aussi bien qu'un python, dotNet ou autre langage managé, voir même mieux. Mais un gros problème reste ce fameux temps de lancement. Ce tutorial cherche donc une solution dans un produit pas très connu, nailgun en prenant comme exemple le génial beanshell.