Comme chaque année, il faut déclarer ses impôts sur le revenu. Les années précédentes, j'avais réussi à le faire sans trop de problèmes. Cette année, ma machine étant passée en amd64, je soupçonnais des problèmes et j'avais raison : en une heure, je n'ai pas réussi à faire ma déclaration d'impôts, et j'ai mis moins de trois minutes sous MacOS X.

Je partais quand même avec une longueur d'avance : j'avais déjà un certificat valable jusqu'en 2010, qui a été reconnu d'office. J'ai ainsi pu remplir ma déclaration d'impôt (format PKCS 12, que j'ai pu exporter et mettre sur mon Mac pour finir la déclaration). Mais au moment de signer la déclaration, il faut exécuter une applet java, qui permettait la signature proprement-dite (au sens cryptographique du terme). Et là, plus possible.

• Sun n'a pas publié de plugin compatible amd64 et ne prévoit pas de le faire avant début 2009...
• openjdk-6 n'est pas fabriqué pour Debian
• Le plugin d'IcedTea ne fonctionne pas pour les impôts (fenêtre grise vide).
• Blackdown Java est introuvable... et avant ça, j'en avais une vieille copie qui fonctionnait à certains endroits mais faisait des segfaults systématiques sur cette applet-là.
• Monter un chroot pour iceweasel n'a pas l'air de fonctionner dans le temps imparti (même avec un xhost + il n'arrive pas à ouvrir de fenêtres graphiques)...

Enfin bref, conclusion : j'ai fait sur un Mac, et ces conneries m'emmerdent.

Un nouvel exemple de migration (après [0],[1] et [2]) qui concerne cette fois un serveur de messagerie (Postfix/Courier-IMAP/OpenLDAP/Amavis/SpamAssassin/Horde) et d’un intranet (Apache/PHP/MySQL) pour plusieurs centaines d’utilisateurs. La migration a duré environ 3 heures (pizzas comprises) sans accroc majeur mais avec un bon nombre de remarques plus ou moins importantes :

- Les Release Notes dispensent de bons conseils : Backup any data, inform users in advance, etc. J’ajoute que je préconise de prévoir une période d’arrêt des services d’au moins une heure avec quelques heures de marge au cas où (dans pas mal de cas, cela peut correspondre à prévoir cela un soir et se réserver la possibilité de passer la nuit dessus !). Je dis bien que je conseille d’arrêter les services (par exemple, mettre en place des règles de firewall les rendant inaccessibles) : en effet prenons l’exemple d’un service SMTP, il est nécessaire de bien vérifier que le système mis-à-jour est fonctionnel avant d’autoriser à nouveau les mails entrants (car si un problème survient, on risque de perdre des mails). Bien sûr, si aucun arrêt n’est possible, une infrastructure permettant une tolérance de panne est sûrement place et l’arrêt des services sur une machine ne posera pas de problème.

- J’utilise en général un noyau Linux patché grsec sur les serveurs mail ou web. Et avant une mise-à-jour majeure, j’ai pris l’habitude redémarrer sur un noyau non-grsec, à savoir celui par défaut… sauf quand il ne contenait pas les pilotes du controleur RAID/SCSI. À retenir :-)
Toujours au sujet du noyau, après quelques installations/désinstallations de noyaux, le paquet module-init-tools a disparu, d’où d’inquiétants messages QM_MODULES: Function not implemented. Solution triviale : aptitude install module-init-tools.

- J’ai perdu mon périphérique /dev/megadev0 (correspondant au controleur RAID/SCSI) que j’ai du recréé via mknod /dev/megadev0 c 253 0 pour avoir un monitoring fonctionnel.

- Un problème de conflit entre les paquets libfam0 et libfam0c102 s’est posé, empêchant d’ailleurs de préparer la mise-à-jour avec un aptitude -d dist-upgrade pour télécharger d’avance tous les paquets à mettre à jour (j’ai finalement du le faire en précisant les paquets manuellement). Pour forcer la résolution de ce conflit : aptitude install libfam0.

- J’ai obtenu l’erreur suivante pendant la mise-à-jour : E: Internal Error, Could not perform immediate configuration (2) on debian-archive-keyring Ack! Something bad happened while installing packages. Pour la résoudre : aptitude install debian-archive-keyring.

- Parlons Apache/PHP/MySQL. En ce qui concerne la migration d’Apache, aucun problème. Pour MySQL 4 vers 5, rien à noter non plus mis à part de bien conserver les mots de passe compatibles avec la v4 (old_passwords=1) comme nous le propose debconf. Enfin pour PHP, je suis resté (pour le moment) sur la version 4 car l’Intranet tourne sous Typo3 et le module calendrier en place semble être incompatible avec PHP5. J’ai eu par contre une activation “surprise” du module eaccelerator dans le php.ini : PHP Warning: Unknown(): Unable to load dynamic library ‘/usr/lib/php4/20050606+lfs/eaccelerator.so’ - /usr/lib/php4/20050606+lfs/eaccelerator.so: cannot open shared object file: No such file or directory in Unknown on line 0

- Pour SpamAssassin, mettre à jour les require_version des règles sur mesure ! Et quelques adaptations mineures (ok_languages, use_dcc plus valables).

- Quelques petits coups de pioche à mettre :

freshclam: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied

Solution : execstack -c /usr/lib/libgmp.so.3.3.3

Uncaught exception from user code: Can’t load ‘/usr/lib/perl5/auto/Quota/Quota.so’ for module Quota: /usr/lib/perl5/auto/Quota/Quota.so: cannot enable executable stack as shared object requires: Permission denied at /usr/lib/perl/5.8/DynaLoader.pm line 225, <DATA> line 225. at ./add.pl line 26

Solution : execstack -c /usr/lib/perl5/auto/Quota/Quota.so

- Pour garder Vim en tant qu’éditeur par défaut (aucun troll n’est caché dans ce point…), ne pas oublier le fameux update-alternatives –config editor

- Pour Courier-LDAP, la syntaxe a apparemment changé :
authdaemond: You need to specify a ldap server in config file
authdaemond: authldaplib: error in LDAP configuration file, aborting

Il faut désormais préciser LDAP_URI (LDAP_SERVER et LDAP_PORT ne sont plus valables) :

#LDAP_SERVER 127.0.0.1
#LDAP_PORT 389 LDAP_URI ldap://127.0.0.1

- Postfix 2.3 génère maintenant par défaut des DSN (Delivery Status Notifications) qui peuvent s’avérer gênantes avec les demandes de confirmation de lecture d’Outlook. Pour désactiver les DSN, ajouter dans le main.cf : smtpd_discard_ehlo_keywords = silent-discard, dsn

Voilà, ce fut donc loin de passer comme une lettre à la poste, mais ça ne fut pas un calvaire non plus. Les services ont été réactivés en temps et en heure, et aucun soucis majeur ne s’est produit dans les jours suivants. Au serveur suivant !

Deuxième partie de ce « HOWTO se mettre à son compte ». Voyons aujourd'hui les différentes charges financières à prévoir. Elles se divisent en deux principales catégories : les charges fiscales (taxes et impôts), et les charges sociales (cotisations). Leur mode de calcul et de perception est loin d'être unifié, donc accrochez-vous.

Imposition des bénéfices

Les bénéfices réalisés (on l'espère) par l'entreprise sont soumis à un impôt. Le calcul du montant de cet impôt nécessite la connaissance des bénéfices à imposer, et les bénéfices de l'année N sont donc imposés en N+1 comme pour l'impôt sur le revenu. Dans certains cas, d'ailleurs, cette imposition est celle de l'impôt sur le revenu. Dans d'autres cas, il s'agit de l'impôt sur les sociétés.

En impôt sur le revenu

Dans le cas d'une entreprise individuelle, comme il n'y a pas de séparation entre l'entreprise et l'entrepreneur, les bénéfices sont imposés dans le cadre de l'impôt sur le revenu, avec une déclaration supplémentaire. Selon le montant du chiffre d'affaires, deux types de déclarations sont possibles. Le régime « micro » est le plus simple, et considère que les frais professionnels représentent une fraction forfaitaire (37 %) des recettes. L'entrepreneur est alors imposé comme s'il percevait la fraction restante en tant que salaire. La comptabilité est très simplifiée, et se résume quasiment à une simple addition annuelle des montants des factures réglées.

Le régime « réel » impose une comptabilité plus complexe. En contrepartie, l'entreprise est imposée sur ses bénéfices réels, et non sur une fraction constante de ses recettes. Si les frais professionnels (déplacements, sous-traitance, services externes) sont élevés et qu'ils dépassent les 37% forfaitaires, il est donc intéressant d'utiliser ce régime réel.

Note en passant : le choix du régime « micro » n'est possible que dans le cas d'une entreprise individuelle ne dépassant pas 27000€ de recettes par an. Au-delà, le régime « réel » est obligatoire.

D'une manière ou d'une autre, le résultat de l'entreprise est intégré dans le revenu de l'entrepreneur, donc soumis au barême habituel de l'impôt sur le revenu (quotient familial, tranches d'imposition, demi-parts supplémentaires, etc.).

En impôt sur les sociétés

Dans le cas d'une SARL, le régime fiscal est celui de l'impôt sur les sociétés. La société est imposée sur ses bénéfices, c'est-à-dire sur la différence entre ses recettes et ses frais. Parmi les frais, les rémunérations des employés et du gérant ne seront donc pas imposés pour la société ; mais ils entreront bien sûr dans les revenus des personnes concernées, et seront donc imposés au titre de l'impôt sur leur revenu.

Une EURL est généralement imposée au titre de l'impôt sur le revenu, mais son gérant peut décider de la faire migrer vers le statut fiscal de l'impôt sur les sociétés. Attention, cette migration est définitive.

L'impôt sur les sociétés se base sur les bénéfices réalisés, et fonctionne selon deux taux. Le taux normal, de l'ordre de 30 %, s'applique dans le cas général ; le taux réduit, de l'ordre de 15 %, est soumis à conditions (bénéfices en-deçà d'un plafond de quelque 7 millions d'euros, confortable pour un freelance) et ne s'applique qu'aux 38120 premiers euros, le reste étant imposé au taux normal.

TVA

La TVA est un impôt indirect, qui est collecté par le vendeur lors de toute vente de biens ou de services, et reversé à l'État. Comme elle ne porte que sur la valeur ajoutée, la TVA reversée est seulement la différence entre le montant de TVA reçue par une entreprise de ses clients et le montant de TVA payée par cette entreprise à ses fournisseurs.

Les entreprises dont le chiffre d'affaires est inférieur à un certain seuil (27000€ pour les prestations de services, 76300€ pour les ventes de marchandises) peuvent bénéficier du dispositif de franchise de TVA. Ces entreprises peuvent alors se passer de faire figurer la TVA sur leurs factures (ce qui peut être intéressant si les clients ne sont pas des entreprises habilitées à récupérer la TVA, par exemple s'il s'agit de particuliers ou d'associations).

La TVA à reverser se calcule simplement : elle est constituée de la différence entre la TVA collectée auprès des clients et celle payée aux fournisseurs. Ce calcul peut se faire tous les ans, tous les trimestres ou tous les mois, et le versement correspondant a lieu rapidement.

Il y a quelques subtilités à connaître pour les clients étrangers (et même, ça dépend s'ils font partie de l'Union européenne ou pas), mais ça ne va pas chercher bien loin.

Taxe professionnelle

Cette taxe est encore d'une simplicité formidable : elle est collectée localement (par le département si mes souvenirs sont bons), mais son calcul est déterminé par l'addition de trois parts, perçues par la commune, le département et l'État, avec donc trois taux différents déterminés par trois collectivités différentes. Ça prend en compte les bénéfices réalisés, mais aussi la valeur locative des outils de travail et des tas de trucs bizarres. Et il y a des planchers incompressibles, ce qui peut surprendre la première année si l'on n'a eu que de faibles revenus et qu'on se retrouve avec une grosse proportion de ces revenus à reverser.

Cotisations sociales

Ce terme assez large regroupe les cotisations versées à différentes caisses qui reversent les prestations sociales. On y trouve notamment :

• les cotisations d'allocations familiales, versées à l'URSSAF ;

• les cotisations d'assurance maladie, versées à une caisse d'assurance maladie (RAM par exemple) et éventuellement à une mutuelle ;

• les cotisations d'assurance vieillesse (retraite), versées à une autre caisse (CIPAV ou autre, ça dépend des professions) ; il est ici aussi possible de prendre une assurance complémentaire, mais c'est le même organisme qui la collecte.

Y figurent aussi les cotisations dites de « prévoyance », c'est-à-dire d'assurance invalidité-décès, ainsi que des trucs que j'ai pas encore trop compris (CSG, CRDS et tout le tintouin).

Ces cotisations ne sont pas calculées sur l'activité de l'année précédente, mais sur celle d'avant. Ainsi, un entrepreneur qui débute son activité en 2008 paiera des cotisations forfaitaires en 2008 et 2009, et ce n'est qu'en 2010 que sera régularisé l'éventuel trop-perçu de 2008. Pour les années suivantes, le forfaitaire pur est remplacé par une estimation des bénéfices, mais il reste le principe de la régularisation en N+2.

Combien ?

La question que tout le monde se pose : combien ça coûte, et combien il reste à la fin ? Évidemment, et malheureusement, la réponse n'est pas simple. Déjà parce que le mode de calcul diffère selon les charges (forfaitaire, régularisé, année N-1 ou N-2, voire trimestre ou mois), mais aussi parce que d'une année sur l'autre, l'entreprise qui grossit un peu franchit les plafonds et change donc de statut donc de mode de calcul. Et les taux retenus par les caisses changent, et si on a un travail salarié à côté la tranche d'imposition ne dépend pas uniquement des revenus de l'entreprise, etc. Mon impression (et après 4 ans d'entreprise je n'ai toujours pas atteint un régime de croisière stable, donc c'est à prendre avec des pincettes) est qu'en gros, pour 100 € facturés, il en reste entre 40 et 50 après cotisations, contributions, taxes et impôts. J'insiste cependant sur le fait que ça s'applique à mon cas particulier, et que ce chiffre varie probablement d'une entreprise à l'autre, suivant l'activité et le mode de fonctionnement (donc l'ampleur des frais et des fournisseurs).

Notons en passant qu'il existe des mécanismes d'exonération de charges pour les entreprises répondant à certaines conditions (jeune entreprise innovante, création d'emploi, zone franche ou défavorisée, etc.). Ça peut permettre de commencer son activité avec une certaine sérénité financière, à condition de planifier pour ne pas se retrouver le bec dans l'eau lorsque ces exonérations sont levées...

Ainsi finit cette deuxième partie. C'est pas très précis, mais c'est parce que c'est vraiment compliqué pour calculer tout ça (heureusement, c'est en général pris en charge par les différentes caisses). La troisième (et probablement dernière) partie redeviendra un peu plus terre-à-terre, et traitera des formalités concrètes de création ainsi que du fonctionnement quotidien de l'entreprise.

Autant pour ne pas oublier que pour en faire profiter les amis, voici une méthode rapide pour mettre en place l'IPv6 par la méthode de transition 6to4 sur une machine Linux.

Pré-requis : un ordinateur sous un noyau Linux un peu récent (pas d'inquiétude, ça marche même avec une Debian stable, que les mauvaises langues se plaisent pourtant à qualifier d'obsolète dès sa sortie). Avec une adresse IPv4 publique fixe.

Première étape : ajouter ce qui va bien dans le fichier /etc/network/interfaces. Pour pas s'embêter, on prend le script suivant qu'on appelle avec ./6to4.sh <adressev4>, et on copicolle le résultat.

#! /bin/sh
set -e

ip4=$1
echo "$ip4" | grep -q '^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*$' || \
{ echo 'Syntax: $0 a.b.c.d'; exit 1; }

ip6=$(printf '2002:%02x%02x:%02x%02x::1' $(echo $ip4 | sed 's/\./ /g'))

sed s/IP6/$ip6/ << EOF
auto sit0
iface sit0 inet6 static
        address IP6
        netmask 64
        gateway ::192.88.99.1
EOF

Deuxième étape : activer cette interface, avec ifup sit0. Pouf, on a de l'IPv6.

Troisième étape, optionnelle : configurer un firewall pour cette interface (attention, c'est avec ip6tables et plus avec iptables).

Quatrième étape, optionnelle aussi : configurer une zone DNS reverse sur un serveur, et faire référencer ce serveur. Ça se passe sur 6to4.nro.net, et il suffit de remplir les champs du formulaire en faisant la requête depuis la machine concernée.

...et voilà. Évidemment ce mini-HOWTO devrait n'être utile que pendant une période limitée (juste le temps que tous les FAI fournissent de l'IPv6 natif), évidemment il ne couvre pas le routage automatique pour le réseau situé derrière la machine, il ne couvre pas les configurations compliquées, mais au moins, pour le prochain serveur dédié que le prendrai, j'aurai la manipulation prête et documentée.

C'est aujourd'hui. Et, comme d'habitude, ça ne change pas grand-chose.

On entend parfois parler dans les magazines d'information de l'arrivée imminente des connexions Internet par fibre optique, utilisant différentes techniques regroupées sous le nom de "FTTH" (fiber to the home, la fibre jusqu'à la maison). Enfin, imminente... apparemment les syndics de certains immeubles commenceraient à être contactés par les opérateurs. Mais ça reste assez limité, et réservé à quelques privilégiés. Pour les autres, ceux qui habitent dans les petites villes (moins de dix millions d'habitants), ça reste assez flou et on sait ni trop comment ça marche, ni quand ça sera réellement disponible.

C'est donc avec une certaine excitation que j'ai participé à une expérimentation pilote pour le déploiement de FTTH (dans sa variante FTTH-PY, pour ceux qui connaissent). Je n'ai pas pu tester en profondeur, faute de préparation préalable (mea culpa), je ne peux donc vous livrer que mes premières impressions.

D'abord, la disponibilité du matériel : impression très favorable de ce côté-là, on peut trouver les équipements d'émission/réception en grande surface sans problème (testé dans une seule grande surface, mais je ne pense pas que le Carrefour de chez moi soit plus spécialisé qu'un autre). Pour la fibre elle-même, c'est à peine plus compliqué, mais elle est elle aussi largement disponible dans les magasins spécialisés. Le prix est également très raisonnable, et le système est probablement parmi les moins chers du marché (il entre en concurrence directe avec les réseaux floppynet).

Pour la mise en place, c'est pas encore tout-à-fait plug and play, hélas. Les contraintes de courbure de la fibre imposées par le système de modulation font que la longueur de la fibre doit être calculée au millimètre près, et ne peut donc pas être connue à l'avance. Il faut donc prendre les mesures soi-même et couper la bonne longueur de fibre. De même, les terminaux étant génériques, ils peuvent s'adapter à plusieurs dimensions de fibre, et il faut les préparer à recevoir la bonne. Il faut également effectuer le raccordement proprement dit. Ça reste très accessible (pas besoin de pince à sertir ou d'outillage particulier), et le tout peut être réglé en quelques minutes, mais on espère que la standardisation aidant ça pourra être simplifié pour les versions finales.

Arrive le gros point noir : le FTTH-PY est censé, à terme, permettre de faire transiter plusieurs types de communications, que ce soit de la voix ou de la donnée, mais pour l'instant seule la voix est réellement opérationnelle. Il n'y a malheureusement pas encore de pilotes disponibles (ni sous Linux, ni a fortiori sous Windows ou Mac OS), et il faut donc passer par des systèmes de conversion des flux de données en signal sonore plus ou moins audible. L'avantage est que ce système de modulation-démodulation (oui oui, c'est un modem) peut être réalisé intégralement en logiciel, l'inconvénient est que les logiciels existants ne sont pas encore à un niveau de stabilité suffisant pour une utilisation réelle. Et même s'ils finissent par y arriver, les prévisions sont pessimistes quant aux performances. Je n'ai donc pas réussi à établir de connexion de données sur ma fibre, j'en suis très déçu. Je ne peux donc que vous transmettre les informations que l'on m'a données, à savoir que les performances attendues pour ce qui concerne les transmissions de données sont de l'ordre de celles obtenues en RFC1149 (IPoAC) pour ce qui concerne le débit et les taux d'erreur, mais sans les problèmes de latence variable. C'est prometteur, mais encore une fois, j'ai pas testé donc je peux pas confirmer.

J'ai donc principalement testé la voix, avec des résultats plutôt positifs. C'est un peu nasillard, mais on peut aisément reconnaître la voix de son interlocuteur. Et je n'ai à aucun moment rencontré les problèmes classiques des nouvelles solutions de téléphonie, notamment VOIP : pas d'écho, absolument aucun effet Larsen, pas de micro-coupure... Également, pour autant que ce soit réellement mesurable à l'oreille (je ne dispose pas de bancs de tests sérieux pour ce genre de mesures), il semble que le temps de propagation soit raisonnablement rapide, ce qui est particulièrement appréciable pour les conversations. En revanche, le signal semble perdre en puissance avec la distance. La longueur d'un brin de fibre sera donc calculée en conséquence. Pour les communications plus longues, il faudra mettre en place des répéteurs, mais la qualité du signal s'en ressent, la voix des interlocuteurs étant pas mal altérée voire rendue méconnaissable selon les répéteurs.

Je n'ai hélas pas pu pousser mes tests au-delà, et je ne peux donc vous donner que cet aperçu très partiel.

Mon verdict : de ce que j'ai pu en voir, le FTTH-PY me semble avoir encore du chemin à faire. Les applications de voix sont actuellement bien traitées, mais la transmission de données n'en est encore qu'à ses balbutiements, et je crains que les concurrents dans la course pour le marché FTTH n'aient déjà pris une avance trop importante. Ceci dit, il peut probablement subsister sur des marchés de niche, en raison de son très faible coût de mise en place et de maintenance. À titre d'exemple, un réseau point-à-point de deux postes peut être entièrement constitué pour le prix de deux pots de yaourt et de dix mètres de fil de pêche.

Pour terminer, je voudrais remercier Philippe, qui travaille chez l'opérateur télécom, pour m'avoir proposé de (et encouragé à) participer à cette expérimentation, et sans qui ce billet n'aurait pas été écrit.

Depuis la réinstallation de ma machine (depuis zéro), je n'avais pas remis en place de webmail. Avant, j'utilisais horde, bien connu des premiers utilisateurs de Free par exemple. C'est sûrement très puissant, mais j'utilise le webmail de façon extrêmement ponctuelle, quand je suis en déplacement dans un endroit qui ne laisse pas passer les connexions ssh. Il est aussi assez complexe à installer.

Mercredi, il y a deux semaines, je me suis retrouvé dans un tel endroit. Si j'ai un webmail fourni par mon travail, là, je voulais consulter une boîte à lettres spécifique de mon serveur ; ça n'allait plus du tout. J'ai rongé mon frein toute la journée, puis je suis revenu sur le problème ce matin. J'ai réussi à tout faire en moins de 30 minutes, tout compris, et sans avoir d'idée au préalable de ce qu'il fallait faire (je n'avais jamais lu la documentation du logiciel, à peine regardé les captures d'écran sur le site en question). Félicitations à Roundcube !

Au menu :

• La veille, préparer un petit nom de domaine spécifique pour ranger son webmail (par exemple, webmail.mondomaine.fr) en tapotant dans son navigateur préféré pour causer avec son gestionnaire de noms (on peut faire avec n'importe quoi d'autre, mais j'aime bien un nom pour un service). Laisser diffuser (toute la nuit).
• Créer un hôte virtuel. Recommencer parce qu'on se rend compte qu'on avait oublié de repasser super-utilisateur (jeter les morceaux non-utiles de la première tentative). J'ai un script qui me fait ça bien, en entrant le truc dans awstats, et me prépare tout ce qu'il faut.
• Éditer l'hôte virtuel pour qu'il agisse en SSL (https), parce que des mots de passe vont quand même être diffusés sur ce canal. Activer PHP5 pour cet hôte (j'ai une préférence pour l'activation avec FastCGI, me servant ponctuellement seulement de PHP ; moins d'encombrement mémoire quand je ne m'en sers pas, et possibilité d'utiliser les démons efficaces d'Apache).
• Générer un certificat qui accepte le nouveau nom webmail.mondomaine.fr en plus des autres.
• Redémarrer Apache. Vérifier qu'on obtient bien un fichier rangé dans la racine du nouveau domaine.
• sudo aptitude install roundcube et suivre les instructions. Il faut juste connaître le mot de passe de sa base de données (je le connaissais).
• Patauger cinq minutes pour être sûr de ce qu'il faut mettre. Se mettre dans la racine du nouveau domaine, et faire un for i in /var/lib/roundcube/*; do ln -s $i; done. Recopier un fichier de lancement de php5 depuis un autre répertoire.
• Pointer son navigateur sur https://webmail.mondomaine.fr/. Tester une première connexion. Tout marche. Constater que la connexion au serveur n'est pas en https, et qu'on ne peut pas du coup se connecter directement aux autres serveurs (celui de mon laboratoire, par exemple).
• Modifier une ligne de config/main.inc.php pour faire apparaître à la place $rcmail_config['default_host'] = array('ssl://monimap.mondomaine.fr','ssl://mail.monboulot.fr','ssl://monautreserveur.fr');. Laisser refroidir, c'est prêt.

Voici le fichier final dans /etc/apache2/sites-available/webmail.mondomaine.fr et juste derrière celui pour lancer FCGI :

<virtualHost *:443="">
DocumentRoot /var/www/webmail.mondomaine.fr/
ServerName webmail.mondomaine.fr
ErrorLog /var/log/apache2/webmail.mondomaine.fr/error.log
CustomLog /var/log/apache2/webmail.mondomaine.fr/access.log combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/oberon.mondomaine.fr.crt
SSLCertificateKeyFile /etc/apache2/ssl/oberon.mondomaine.fr.key
ServerAdmin monadresse@chezmoi.fr
AddDefaultCharset utf-8
DirectoryIndex index.html index.php
#  Uncomment to use PHP5
AddHandler fastcgi-script .fcgi
AddHandler php-fastcgi .php
AddHandler php5-fastcgi .php5
Action php-fastcgi /php5-wrapper.fcgi
Action php5-fastcgi /php5-wrapper.fcgi
</VirtualHost>

#!/bin/dash
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=1000
export PHP_FCGI_MAX_REQUESTS
exec /usr/bin/php5-cgi

[Ajout] : J'ai dû aussi modifier une autre ligne, pour mettre $rcmail_config['create_default_folders'] = TRUE;. Sinon, je ne pouvais pas effacer les messages.

Je m'aperçois que ce Freelance HOWTO, que j'avais promis il y a fort longtemps déjà, n'a toujours pas été écrit. Donc, je m'y mets. Comme c'est un peu long, ce sera en plusieurs parties. La première restera assez générale ; je n'ai pas encore rédigé les suivantes, mais il est probable qu'il y en aura trois au final.

Buts et contexte

Je suis monsieur M., j'ai acquis des compétences d'une manière ou d'une autre, et je pense qu'il y a un marché et que je pourrais essayer de vivre de ces compétences. Je vais donc créer mon entreprise, pour proposer mes services à des clients contre rémunération, soit à temps partiel (par exemple pour tâter le terrain) soit à temps plein (une fois que je suis convaincu de la viabilité de mon entreprise).

(Ce HOWTO se focalise sur les entreprises de services. Pour les entreprises qui font plutôt du commerce, c'est-à-dire de l'achat et de la revente de produits, les contraintes sont un peu différentes, et je connais moins le domaine, donc demandez un avis plus éclairé.)

Préalables

Avant de se lancer et de prendre le moindre engagement, il convient de se demander si les chances de l'entreprise sont raisonnables. Théoriquement, il faudrait faire (ou faire faire) une étude de marché complète, mais ça peut coûter cher. Commencer par essayer de se faire une idée des réponses aux questions suivantes : Y a-t-il réellement un besoin ? Des clients ? Ces clients sont-ils prêts à payer pour le service rendu ? Y a-t-il déjà des entreprises qui fournissent le service à ces clients ? Si oui, reste-t-il de la place pour une de plus ?

En fonction de ces réponses, on pourra déjà dans certains cas avoir une idée de la viabilité du projet. Si c'est pas bon, il est conseillé d'arrêter, ou de faire évoluer le projet pour que ça devienne bon.

Forme juridique

Une « entreprise » peut avoir plusieurs formes, et fonctionner selon plusieurs statuts. Il faut notamment distinguer le statut juridique (la forme sous laquelle l'entreprise existe) et son statut fiscal (la manière selon laquelle les impôts et taxes sont calculés et payés). Les deux sont plus ou moins liés, puisque certaines combinaisons ne sont pas autorisées, mais il reste plusieurs possibilités.

Je ne détaille ici que deux statuts, celui de l'entreprise individuelle et celui de l'EURL/SARL. Les autres statuts (SA, SAS, SCIC etc.) sont plus complexes à mettre en place, et sont de toute manière moins adaptés à l'objet de ce billet, qui vise principalement quelqu'un qui veut « se mettre à son compte ».

Le statut d'entreprise individuelle (EI) est le plus simple. Il consiste simplement à s'enregistrer à l'URSSAF, ce qui donne un numéro SIREN/SIRET, et le droit d'émettre des factures. Il n'y a pas de société, pas de personne morale séparée, l'entreprise et l'entrepreneur sont juridiquement identiques.

Si l'on souhaite séparer l'activité professionnelle et la personne physique, il faut passer par la création d'une société. Pour une activité de petite taille, on crée généralement une SARL, société à responsabilité limitée. Et même, quand on est tout seul, on appelle ça une EURL, entreprise unipersonnelle à responsabilité limitée (c'est juste un cas particulier de SARL, qui ne change pas grand-chose au fonctionnement). La création d'une SARL/EURL passe par des formalités plus complexes : rédaction de statuts de société par un juriste, publication dans un journal d'annonces légales, inscription au registre du commerce et des sociétés, etc. La contrepartie est cette séparation des biens entre l'entreprise et l'entrepreneur.

Séparation toute relative, ceci dit : si la société fait faillite, la responsabilité du gérant pourra quand même être mise en jeu en cas de gestion manifestement mauvaise. Et même sans parler de ce cas extrême, il faut garder à l'esprit que les dettes de l'entreprise correspondront souvent à des emprunts, et que ces emprunts ne seront probablement accordés qu'avec des garanties personnelles de l'entrepreneur.

Fin de cette première partie. La prochaine fois, nous verrons ce qui est perçu (ou présenté) comme le frein majeur qui décourage l'entreprenariat français : les charges (sociales et fiscales).

Quand j'étais petit, on avait dans ma cour d'école une blague/devinette qui nous faisait beaucoup rire :

Quelle est la différence entre un dollar et un rouble ?
Réponse : Un dollar !

Pour remettre dans le contexte : à l'époque, l'étranger se divisait en deux catégories. Il y avait d'un côté les Américains, riches et puissants, et de l'autre les Russes, dont il fallait se méfier parce qu'ils étaient puissants aussi, bien qu'on ne sache pas trop comment. Les Russes n'avaient pas d'argent ou presque, le peu qu'ils avaient ne valait pas grand-chose, et de toute façon ils ne pouvaient rien en faire puisque leurs magasins étaient vides. Et c'était bien fait pour eux, puisque c'était eux les méchants (la preuve : nous, les gentils par définition, on était copains avec les Ricains).

Le monde a un peu changé depuis, mais cette blague pourra bientôt être remise au goût du jour, à peine modifiée :

Quelle est la différence entre un dollar et un euro ?
Réponse : Un dollar !

(OK, aujourd'hui c'est juste 0,57 dollar, mais ça va monter, patience.)

Après les épisodes [0] et [1], voici la mise-à-jour d’un poste de travail mono-utilisateur KDE/Mozilla/OpenOffice, en place depuis 2 ans environ dans une association. Les remarques concernant la migration sont les suivantes :

- Au niveau de la mise-à-jour complète des paquets (le dist-upgrade), il a été nécessaire de forcer la mise-à-jour de KDE. En effet, aptitude install kde a permis la désinstallation des paquets libhal0 et dbus-1 spécifiques à Sarge.

- Il a été nécessaire de récupérer manuellement la clé GPG pour authentifier les paquets avec aptitude.

- Au niveau de KDE, les icônes sur le bureau ont été désorganisés (tous rassemblés en haut à gauche) et l’application KGPG était lancée par défaut (à désactiver car non utilisée dans ce cas précis).

Bref, surtout des détails. Aucun soucis au niveau de Firefox->Iceweasel et Thunderbird->Icedove (le plus gênant était le changement des… icônes), au niveau d’OpenOffice v1->v2, CUPS, GAIM, etc. La conclusion de cette mise-à-jour a été : « C’est réparti pour 2 ans de stabilité ! » Qui a dit que Debian n’était pas prêt pour le poste de travail en environnement professionnel ?

Une nouvelle version de Lightning, qui corrige plein de bugs, qui fait suite à d'autres articles dans ce blog. La version 0.7 remplace la version 0.5 précédente. J'ai recompilé rapidement l'extension sur une installation toute propre de Icedove 2.0.0.6. J'ai mis un peu de temps à trouver les sources qui ont bougé par rapport à la version 0.5. À noter que la mise à jour de Google Provider for Sunbird/Lightning nécessite la mise à jour. Comme d'habitude, il faut recompiler cette extension pour Icedove (Thunderbird™ pour Debian).

Je détaille à nouveau la procédure suivie pour le recompiler (je suppose que pbuilder est installé, suit unstable et fonctionne correctement) :

• pbuilder update; pbuilder login
• Modifier /etc/apt/sources.list pour y faire apparaître le dépôt source
• apt-get update; apt-get install wget; apt-get build-dep icedove; apt-get source icedove
• cd icedove-2.0.0.6; tar xjf icedove-source-2.0.0.6.tar.bz2
• wget http://releases.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/0.7/source/lightning-sunbird-0.7-source.tar.bz2
• tar xjf lightning-sunbird-0.7-source.tar.bz2 mozilla/calendar
• rm icedove-2.0.0.6.tar.bz2;tar cjf icedove-2.0.0.6.tar.bz2 mozilla/;rm lightning-sunbird-0.7-source.tar.bz2
• Modifier debian/rules pour faire apparaître (ligne 71) --enable-extensions=default,lightning \ à la place de --enable-extensions=default \
• debian/rules binary
• Faire autre chose pendant un bon moment
• cd build-tree/mozilla/dist/xpi-stage/
• wget http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.7/lightning-0.7.linux-i686.xpi
• mkdir tmp;cd tmp;unzip ../lightning.xpi; unzip ../lightning-0.7.linux-i686.xpi et accepter toutes les modifications dans chrome/ (et aussi chrome.manifest).
• zip -r ../lightning-0.7-icedove-amd64.xpi . (ou bien i686)
• Quand tout ceci est enfin fini, recopier (depuis l'extérieur du chroot créé par pbuilder) le fichier qui se trouve dans .../icedove-2.0.0.6/build-tree/mozilla/dist/xpi-stage/lightning-0.7-icedove-amd64.xpi. L'installer dans Icedove (Tools → Add-ons → Install ou Outils → Modules complémentaires → Installer). Servir frais.

Pour ceux qui ont patienté jusqu'au bout, j'ai attaché les fichiers (avec les traductions, donc) à cet article, compilés pour amd64 ou i386.

L'un des premiers économiseurs d'écrans que j'ai eu était une sorte d'aquarium virtuel. Bon, des poissons plats passaient de gauche à droite et de droite à gauche devant l'écran.

Depuis longtemps, on peut utiliser plusieurs « écrans » sous Linux. On les considère souvent rangés à côté les uns des autres. On peut même imaginer que le premier est à nouveau à droite du dernier, faisant un anneau. On laisse ses fenêtres de travail sur un des écrans, le courrier sur un deuxième, etc. Quand on change d'écran, on ne voit plus les fenêtres des autres écrans (virtuels). Je ne suis pas Terry Pratchett¹, je n'ai pas six moniteurs pour travailler.²

Maintenant, pour gérer l'affichage de mes fenêtres, j'utilise la toute nouvelle interface Compiz-fusion. Elle n'est pas distribuée en standard dans Debian, mais on la trouve dans le dépôt de Shame. Elle permet de faire des tas de choses (tournoyer son écran, rendre translucide des fenêtres qui sont molles quand on les bouge...) Rien de très intéressant (enfin, si : ça a un taux de geekitude très élevé). Note technique : j'ai dû utilisé la méthode ini pour stocker la configuration au lieu de gconf.

Jusqu'à ce que je trouve le greffon Atlantis.

Capture d'écran avec le greffon « Atlantis » : un aquarium est caché derrière votre écran

Oui, ça ne sert à rien. Lorsqu'on tourne (avec la souris) son « cube de bureau » (et oui, il y a une face au-dessus et au-dessous), on voit apparaître des baleines et des requins qui nagent derrière. En temps réel. En trois dimensions. Non, non, c'est bien plus beau lorsque c'est inutile !

1 : Authentique (source, moi).

2 : Authentique (source, Terry Pratchett, Discworld Convention 2006).

J'utilise Emacs pour un certain nombre d'activités (principalement quand je tape en LaTeX, en Perl et en Postscript).

Une nouvelle avait attiré mon attention il y a quelque temps. Emacs est donc maintenant capable d'utiliser toutes les polices du système, à n'importe quelle taille. À la suite de la requête d'un collègue, j'en ai profité pour le tester... et l'adopter.

La méthode était facile au laboratoire, installé en architecture i386. En effet, Ubuntu (ou un de ses développeurs ou utilisateur : Alexandre Vassalotti) fournit des paquets pour emacs-snapshot qui utilisent la branche emacs-unicode-2 de développement. Recompiler ça ne m'a pas posé de problèmes.

À la maison, ma machine utilise l'architecture amd64, non prévue par M. Vassalotti. Il a donc fallu recommencer le travail (un quart d'heure, environ).

• Mettre à jour mon installation de pbuilder (il faudra que je fasse un tutorial un jour là-dessus, mais il y en a déjà tellement...
• cd /tmp;wget http://debs.peadrop.com/pool/feisty/backports/emacs-snapshot_20070705.orig.tar.gz
• wget http://debs.peadrop.com/pool/feisty/backports/emacs-snapshot_20070705-1.dsc
• wget http://debs.peadrop.com/pool/feisty/backports/emacs-snapshot_20070705-1.diff.gz
• sudo pbuilder build emacs-snapshot_20070705-1.dsc
• Le résultat est une série de paquets dans votre emplacement de résultats (par défaut /var/cache/pbuilder/result). J'ai installé les paquets emacs-snapshot, emacs-snapshot-bin-common, emacs-snapshot-common et emacs-snapshot-gtk, puis mis en mode automatique tous sauf le dernier (aptitude markauto emacs-snapshot emacs-snapshot-bin-common emacs-snapshot-common).

Exceptionnellement, je ne mettrai pas le résultat de la compilation sur ce blog ; le paquet fait plus de 20 Mo (c'est gros, emacs). On le trouve sur mon miroir partiel (comme d'habitude) et j'incite plutôt les gens à le recompiler par eux-même (comme d'habitude).

Maintenant, je veux maintenir la compatibilité avec la version stable d'Emacs (22). Pour cela j'ai inséré dans mon .emacs :

(setq running-emacs-23 (> emacs-major-version 22))

(if running-emacs-23
        (progn
                (set-default-font "Monospace-11")
        )
)
(setq inhibit-startup-message t)

NB : Le progn n'est nécessaire que si on veut faire plusieurs réglages séparés. Pour le moment, je n'en ai qu'un. La dernière ligne annule le comportement agaçant (pour moi) de l'écran de publicité au démarrage d'Emacs. Quand je lance Emacs, je veux travailler, pas savoir ce que j'utilise (depuis 1993).

Je viens de commencer à installer sérieusement des machines de bureau en 64 bits à mon travail, et ça me donne l'occasion de me heurter aux principaux problèmes de la transition en 64 bits: les applications commerciales prévues uniquement pour fonctionner en 32 bits.

Je vais m'attaquer ici aux interfaces fournies par Adobe pour lire le PDF (Acrobat Reader) et le Flash (Plugin flash). Toutefois, cernons un peu le cadre: ces applications fonctionnent sans trop de soucis sur une machine 32 bits, et un des conseils traditionnels est d'installer un chroot en 32 bits, c'est-à-dire une réplique (miniature) d'un système en 32 bits. Si vous choisissez cette méthode, des tas de descriptifs existent ailleurs. Mais je ne voulais pas cette solution, qui souffre de nombreux inconvénients. J'ai donc installé les logiciels sus-cités en biarch, c'est-à-dire avec des bibliothèques systèmes en 32 bits (à côté des bibliothèques systèmes en 64 bits) et l'utilisation d'un mode spécial du processeur (qui accepte les instructions 32 bits comme 64 bits).

Le choix du modèle : chroot ou biarch ?

Le premier choix a été d'éliminer la méthode du chroot, pour ses multiples inconvénients :

1. Un chroot en 32 bits a besoin d'être mis à jour, comme un vrai système. Ce qui est bien pour un système personnel, mais quand on gère des machines en grand nombre, ce n'est pas agréable.
2. Il est possible de faire de l'escalade de droits assez facilement à l'intérieur d'un chroot, en tout cas plus facilement qu'à l'intérieur d'un vrai système. Ce n'est qu'un quart de demi-problème (de toute façon, nous utilisons NFS).
3. Il faut dupliquer les applications et les montages. Nous utilisons beaucoup de montages, et si on veut que tout soit accessible de la même façon, il faut répliquer les montages. Dans pas mal de configurations, par exemple, le répertoire /tmp n'est pas le même dans le chroot que dans le système natif, et c'est très perturbant (surtout que certains programmes déposent leurs résultats dans ce répertoire, par exemple chez nous cups-pdf). De plus ça gâche de l'espace (et jusqu'à quel point faut-il dupliquer) ?
4. Il faut penser à lancer le programme en 32 bits dès le début, et pas seulement au moment où on a besoin de la compatibilité 32 bits. Les programmes doivent être lancés avec une syntaxe particulière.

Il y en a d'autres, sans doute. J'étais déjà convaincu.

Acroread ou le travail déjà tout fait

La pertinence de s'attaquer à acroread se pose : pourquoi ne pas utiliser un des multiples programmes comme xpdf ou evince qui permet d'imprimer du PDF tout aussi bien et plus rapidement que Acrobat Reader ? Parce que bien que j'encourage leur usage, il y a des cas où il s ne sont pas utilisables. Par exemple, les cartes du monde que j'ai fabriquées pour un wargame auquel je participe sont monstrueusement longues à ouvrir parce que xpdf ne fait pas un rendu partiel de l'affichage (surtout quand on zoome), ce que sait faire parfaitement Acrobat Reader sous Linux. De plus, les options d'impression d'Acrobat Reader sont nettement plus riches.

Je connaissais plutôt bien le paquet acroread, mon nom étant déjà dans le changelog. Le travail était déjà presque fait pour Acrobat Reader (dans la FAQ Debian AMD64). Il m'a suffi de prendre le paquet disponible sur le dépôt debian-multimedia (acroread_7.0.9-0.2sarge1_i386.deb). Une fois fait, j'ai fait les modifications suivantes :

• Extraire le contenu du paquet: dpkg -x acroread_7.0.9-0.2sarge1_i386.deb /tmp/acro
• Extraire les méta-données du paquet: dpkg -e acroread_7.0.9-0.2sarge1_i386.deb /tmp/acro/DEBIAN
• Modifier les méta-données du paquet /tmp/acro/DEBIAN/control: ajouter la dépendance sur ia32-libs-gtk et ia32-libs. Changer l'architecture de i386 à amd64.
• Modifier /tmp/acro/usr/bin/acroread pour que les dernières lignes soient:

  export GTK_PATH=/usr/lib32/gtk-2.0/
  export GCONV_PATH=/usr/lib32/gconv
  export PANGO_RC_FILE=/etc/pango32/pangorc
  export GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders.32
  export GTK_IM_MODULE_FILE=/etc/gtk-2.0/gdk.immodules.32
  exec "$ACRO_EXEC_CMD" ${1+"$@"}

• Ré-empaqueter le tout: cd /tmp/acro;dpkg-deb --build; cd ..; mv acro.deb acroread_7.0.9-0.2sarge1_amd64.deb
• Recommencer à faire la même chose pour acroread-escript (il n'y a que l'architecture à changer) et acroread-plugins (il faut supprimer .../usr/lib/Adobe/Acrobat7.0/Reader/intellinux/plug_ins/PPKLite.api car incompatible avec le 64 bits).

On obtient ainsi trois paquets, parfaitement viables et installables sur amd64, et qui fonctionnent très bien. On les trouve sur mon miroir partiel personnel. Je mets ici la liste des trois paquets, mais si jamais un jour je fais une version plus à jour, les liens risquent de ne plus être bons :

• acroread
• acroread-escript
• acroread-plugins

Flash plugin (version Adobe)

Il en est un peu de même que pour acrobat-reader : il y a une alternative qui depuis peu sait même lire les vidéos empaquetées en Flash. Mais tant que la compatibilité n'est pas quasi-parfaite (et des dires même du développeur, il reste du travail), je préfère la sécurité.

Le travail est là-aussi presque complètement fait, à l'exception du détail suivant: le paquet flashplugin-nonfree fonctionne sur les deux architectures (à l'aide en particulier du paquet nspluginwrapper, qui permet de faire fonctionner un plugin 32 bits dans un navigateur Mozilla (Firefox, Iceweasel, etc.) de façon complètement transparente. Le détail était que le paquet n'était pas compilé dans la même version dans les deux architectures, et pour des questions de cohérence du parc, je préférais avoir les mêmes versions. C'est maintenant obsolète comme détail. Donc, c'est fini, et on pouvait voir les images tremblotantes de YouTube s'agiter à l'intérieur d'un navigateur fonctionnant en 64 bits.

LibFlashSupport (support du son par le plugin flash)

Il ne reste en fait qu'un petit détail, mais bon, un détail qui a son importance. C'est que les images de YouTube étaient parfaitement muettes ! Et pire, je savais pourquoi. J'utilise un serveur de son (PulseAudio) qui me sert à faire le multiplexage (écoute simultanée) de multiples canaux sonores. J'ai cru comprendre que ça pouvait être fait par ALSA directement (mais il y a des conditions à ce que j'en ai lu, par exemple l'alerte en rouge ici), mais je n'ai jamais compris comment, et surtout, ça ne marche pas de façon directe et immédiate. La configuration d'ALSA est bien trop ésotérique pour moi. De plus, un serveur de sons à d'autres avantages, comme de régler individuellement (et graphiquement) le volume sonore de chaque flux, la possibilité de transporter le son via le réseau, etc. Enfin bref, je l'utilise, et je n'allais pas m'en passer.

Même sans le serveur de son, le plugin Flash supporte mal la cohabitation avec d'autres sources sonores. Il s'approprie la carte son, et s'il ne peut pas, ne joue pas de son. Si un autre programme s'est comporté pareil (par exemple, le lecteur de musique), on est face à un problème (même si le lecteur de musique est en pause).

La solution, en 32 bits, est d'utiliser libflashsupport fourni par Révolution Linux, une société canadienne du microcosme Linux. C'est parfaitement libre, et ça marche tout seul. CJ van den Berg a fabriqué des paquets Debian qui contiennent ce qu'il faut en 32 bits (même si un peu anciens). Et après avoir essayé, j'ai adopté.

Restait le passage en 64 bits. J'ai le résultat, mais je préviens, c'est sale. libflashsupport est en fait ouvert dynamiquement par le plugin Flash s'il est trouvé (que vous l'ayez ou pas, le plugin essaye de l'ouvrir). Il essaye de l'ouvrir dans les bibliothèques 32 bits. La recompilation du source n'a pas été très difficile, mais là, on se rend compte qu'il faut le recompiler en 32 bits (normal — je ne vais sans doute dire que des banalités, mais ça prend parfois un peu de temps à réaliser). On le recompile dans un chroot i386, et après plusieurs essais, ça ne marche toujours pas. Mffff, pas de quoi, merci, continuons. Et quand on ne sait pas quoi faire, on examine le code. Et que voit-on ? libflashsupport ouvre dynamiquement /usr/lib/libpulse-simple.so pour voir si le plugin Flash doit essayer en priorité d'utiliser PulseAudio au lieu de ALSA directement (ce qui ne marche pas). L'ouverture dynamique se fait pas dlopen(), et ne peut pas fonctionner, puisque /usr/lib/libpulse-simple.so est en 64 bits.

Qu'à cela ne tienne, il suffit de modifier le source. On fait donc ouvrir à libflashsupport uniquement /usr/lib32/libpulse-simple.so (notez la différence). Ainsi, on a une bibliothèque 32 bits ouverte dans une application 32 bits, tout va bien, tout le monde est content. Sauf que la bibliothèque libpulse-simple.so n'est évidemment pas dans les quelques bibliothèques de base incluses dans les paquets ia32-libs et ia32-libs-gtk.

On en arrive à la dernière étape. Où trouver ces bibliothèques ? Après tout, je suis déjà dans le domaine de la bidouille, donc je décide de les copier bêtement de mon chroot i386. Il faut les copier elles, plus toutes leur dépendances nécessaires (libpulse.so, libssl.so, libcrypt.so, libcap.so). Je mets tout ça dans le paquet, et tant pis pour le paquet source !

Le résultat est un petit paquet facile à installer, qui marche bien, et qui a beaucoup de choses sales dedans. Mais ce qui compte, c'est que ça marche, non ?

J'ai déjà parlé de Lightning dans ce blog. La version 0.5 remplace la version 0.3.1 précédente. J'ai recompilé rapidement l'extension sur une installation toute propre de Icedove 2.0.0.4.dfsg1 (mais ça marche sur des versions légèrement antérieures, puisque j'ai encore la 2.0.0.3 quelque part et qu'il n'y a pas de bug évident). Je le recompile car plusieurs personnes m'ont signalé que Icedove est encore incompatible avec l'extension qu'on trouve partout pour i386.

[Mise à jour 16/07/2007] J'ai ajouté un paragraphe correspondant à la fabrication d'un paquet qui contient les données permettant de traduire l'interface de Lightning.

Je détaille un peu la procédure suivie pour le recompiler (je suppose que pbuilder est installé, suit unstable et fonctionne correctement) :

• pbuilder update; pbuilder login
• Modifier /etc/apt/sources.list pour y faire apparaître le dépôt source
• apt-get update; apt-get install wget; apt-get build-dep icedove; apt-get source icedove
• cd icedove-2.0.0.4dfsg1; tar xjf icedove-2.0.0.4.dfsg1-source.tar.bz2
• wget http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.5/source/lightning-sunbird-0.5-source.tar.bz2
• tar xjf lightning-sunbird-0.5-source.tar.bz2 mozilla/calendar
• rm icedove-2.0.0.4.dfsg1-source.tar.bz2;tar cjf icedove-2.0.0.4.dfsg1-source.tar.bz2
• Modifier debian/rules pour faire apparaître (ligne 65) --enable-extensions=default,lightning \ à la place de --enable-extensions=default \
• debian/rules binary
• Faire autre chose pendant un bon moment
• Quand la compilation est finie, recopier (depuis l'extérieur du chroot créé par pbuilder) le fichier qui se trouve dans .../icedove-2.0.0.4.dfsg1/build-tree/mozilla/dist/xpi-stage/lightning.xpi. L'installer dans Icedove (Tools → Add-ons → Install). Servir frais.

[Mise à jour 16/07/2007] Les données de traduction (nécessaires pour que Lightning fonctionne en différentes langues) sont un peu plus compliquées à inclure, car elles ne sont pas incluses dans le code source. Thomas Wassong a réussi à le faire — viele danke, Thomas. La méthode est de télécharger l'un des paquets contenant déjà cette localisation (par exemple lightning-0.5.linux-i686.xpi), le dézipper (un .xpi est en fait un fichier zippé, dézipper le .xpi que vous venez de produire, y mettre tous les fichiers chrome/calendar-xx.jar et chrome/lightning-xx.jar du paquet officiel et rezippez le tout. Non, ce n'est pas propre, mais puisque les données de traduction ne sont pas dans le source...

Depuis déjà plusieurs années, je dois régulièrement mettre à jour les noyaux d'un parc de 80 machines, et parmi ces machines, nombre d'entre elles (de marque Dell) ont des cartes Nvidia. J'installe donc les gestionnaires Nvidia, et comme je dois gérer beaucoup de machines, je l'installe via des paquets Debian.

J'ai dû automatiser la tâche de construire ces paquets. On va me dire « Il y a module-assistant ». C'est vrai. Mais module-assistant ne fait pas le paquet en plusieurs versions de façon automatique. De plus, il y a parfois besoin de bricoler un peu les sources, voire les binaires, comme depuis le noyau 2.6.18-4 (et le problème d'exportation de symbole GPL/non-GPL de paravirt_ops).

Donc, j'ai construit mon élevage à modules. Je donne en argument trois valeurs : la version du noyau pour lequel je veux construire, la version des sources nvidia et la version des sources nvidia-legacy. Je lance mon script, et je finis avec le module NVidia et NVidia-legacy compilé pour les sous-architectures 686, 686-bigmem et k7 (ce sont les différents types de noyau utilisés sur l'ensemble des 80 machines).

J'ai dû récemment modifier mon script pour qu'il tienne compte du bug 419943 (j'aurais pu mentionné plusieurs bugs spécifiquement sur le paquet nvidia-kernel-source, comme 420585). J'en ai profité pour corriger le bug 409204, qui ne nécessitait pas un gros effort.

Je vous livre mon script qui permet de générer le tout. Pour le faire fonctionner, il faut copier les deux scripts prepare et cmdline-nvidia dans un répertoire où il peut être exécuté, installer les paquets nvidia-kernel-source, nvidia-kernel-legacy-source et tous les nvidia-kernel-headers adéquats (par exemple linux-headers-2.6.21-1-686 si on ne veut que du 686) puis invoquer d'abord prepare puis (après avoir mis dans le script les numéros convenables) cmdline-nvidia, puis cmdline-nvidia -legacy. Au bout d'un moment, /var/cache/apt/archives contient les paquets tout chauds.

Si le noyau doit être patché, il suffit de mettre dans /usr/src/nvidia-patches le patch en question. Je vous livre le mien en même temps.

La technique pour faire fonctionner le module même avec paravirt_ops m'a été inspirée par cet article. Il implique de reconstruire linux-kbuild en enlevant les deux lignes suivantes (autour de la ligne 1200) :

if (!mod->gpl_compatible)
    check_for_gpl_usage(exp->export, basename, exp->name);

Tous mes paquets recompilés sont disponibles sur le miroir partiel que je gère. N'hésitez pas à recompiler si vous n'avez pas confiance !

Icedove (connu aussi sous le nom de Thunderbird), le lecteur de courrier de Mozilla, est disponible en version 2.0 sous Debian/sid.

Je ne reviendrais pas sur la raison qui fait que Thunderbird a été renommé en Icedove sous Debian. La raison en est complexe, et d'autres l'ont traité bien mieux que moi. Toujours est-il qu'il y a des subtiles différences, entre autre l'utilisation de bibliothèques systèmes à la place de bibliothèques embarquées, qui font que tout n'est pas toujours compatible entre les deux navigateurs.

L'un des intérêts (pour les utilisateurs de ce logiciel, dont je ne suis pas un utilisateur exclusif, mon lecteur usuel étant mutt) est la possibilité d'y ajouter l'extension Lightning, qui permet de gérer des agendas/calendriers, et qui conjuguée à l'extension Provider for Google Calendar permet de gérer dans son lecteur de courrier les calendriers stockés par ailleurs dans Google Calendar. Pour un nomade (au sens où je change souvent de machine comme moi, c'est un bonheur.

Le principe qui fait que c'est intéressant, c'est que en vadrouille, je peux consulter et modifier depuis n'importe quel navigateur web mes calendriers. Je peux aussi le faire depuis mon portable ou mon poste au laboratoire dans l'interface de Icedove/Thunderbird, même sans connexion réseau.

Malheureusement, pour des raisons assez complexes, Debian ne peut pas se permettre de distribuer une version « officielle » de Icedove. La version distribuée par Debian a pas mal d'optimisations (comme par exemple, d'utiliser les bibliothèques du système, avec les corrections apportées automatiquement par le système, au lieu d'attendre des mises à jour hasardeuses). En plus, elle est libre de droits. Bon, bref, rien de bien intéressant pour le moment.

Là où ça se corse, c'est que de fait, l'extension Lightning téléchargeable un peu partout ne fonctionne pas avec icedove. Peu de messages d'erreur (sinon des horreurs dans la console). Bref, j'allais devoir recompiler.

Méthode employée : créer un chroot avec un système minimale. Installer tout ce qu'il faut pour compiler icedove et le lancer. L'arrêter, modifier les fichiers de configuration pour qu'il fabrique aussi l'extension Lightning. Télécharger le source de Lightning 0.3.1, le coller dans l'arbre de compilation au bon endroit. Attendre (deux heures, mais en faisant autre chose, quand même). Recommencer (pas tout, mais bon) parce qu'on a oublié un changement. Recommencer (même raison).

Au bout d'un moment, on obtient un fichier lightning.xpi. On ouvre Icedove, on clique sur Tools -> Add-ons (la traduction en français n'est pas encore disponible, d'habitude c'est Outils -> Extensions). On installe le fichier sus-mentionné... et on redémarre Icedove.

Et là, alléluia ! *** cal_calendar_schema_version not found; initializing storage provider tables, qu'il nous dit.

C'est bon, ça marche, il ne reste plus qu'à suivre la procédure sur cette page pour ajouter les calendriers déjà existants sur Google Calendar.

En attachement de cet article, j'ai mis le fichier lightning.xpi généré (à vos risques, je ne reprends pas la marchandise, etc.). Le Provider for Google Calendar marche très bien si on prend celui par défaut (il faut le télécharger et l'installer à part, comme sur mon Macintosh d'ailleurs, parce que sinon Iceweasel/Firefox croit que c'est une extension pour lui). Notez bien que je compile pour l'architecture i386, pas pour amd64.

Au passage, merci à buxy de m'avoir ajouté à Debian-Planet-Fr. Je dois les inonder un peu, mais comme je travaille sur des trucs qui ont rapport avec Debian en ce moment (en partie), c'est ce dont j'ai le plus à raconter...

Seahorse est un programme qui remplit trois rôles :

• Gestionnaire de clés (à la fois clés ssh et clés de chiffrement GPG) 
• Agent de cache pour les clés ssh ;
• Agent de cache pour les clés gnupg-agent.

Si l'utilisation de Seahorse dans les deux premiers rôles ne pose aucun problème avec la distribution Debian (sid du 22 mai 2007), il faut faire un peu d'efforts pour la 3e utilisation.

En effet, plusieurs bugs actifs signalent une incompatibilité entre l'installation de gnupg-agent et l'installation de seahorse. Le symptôme est simple : si les deux programment sont exécutés simultanément (avec en particulier seahorse exécuté dans un environnement qui hérite de gnupg-agent, comme c'est le cas par défaut), seahorse meurt (bêtement).

La première solution est relativement simple : il s'agit de ne pas exécuter gnupg-agent alors qu'il est installé. Il suffit (pour ceux qui utilisent la session système, et pas un .xsession personnalisé) d'éditer /etc/X11/Xsession.d/90gnupg-agent, et de l'encadrer par un if [ "0" == "1" ]; then au début et fi à la fin.

La deuxième solution, qui est en fait la plus naturelle, est de ne pas installer du tout gnupg-agent. Bizarrement, c'est également le plus difficile si vous utilisez simultanément KDE et Gnome (ou si vous n'utilisez que l'un des deux), car un des paquets de KDE (à savoir kleopatra) déclare gnupg-agent comme dépendance.

Il serait tout à fait légitime de déclarer gnupg-agent si ce programme était vraiment nécessaire. Mais ce n'est pas le cas, puisque ce dont ce sert kleopatra (l'interface générale de KDE pour divers choses, dont la gestion des clés de kmail) c'est uniquement de la connexion en mode socket avec gnupg-agent, pour laquelle seahorse est parfaitement compatible. Et si ce n'est pas vrai (la compatibilité, j'entends), c'est un bug de seahorse qui pourrait immédiatement être déplacé vers ce paquet (et non pas un bug de kleopatra).

J'ai essayé de convaincre les mainteneurs de KDE de rajouter une alternative à gnupg-agent (il suffit de mettre dans le fichier de contrôle de kleopatra gnupg-agent|seahorse à la place de gnupg-agent dans la ligne des dépendances), mais ça s'est révélé infructueux:

<pusling> then there is no bug ?
<jcdubacq> yes there is ! I cannot install kleopatra without gnupg-agent
<jcdubacq> that is the only bug
<pusling> that's not a bug. that's a feature
<jcdubacq> ?!
<jcdubacq> gnupg-agent is not necessary !
    I can prove it since I do not have it installed, and it works ?!
<jcdubacq> All I ask is to acknowledge that seahorse is a good
    enough replacement for gnupg-agent
<pusling> I don't feel like I can acknowledge that.

Comme la coopération ne fonctionne pas, il est donc nécessaire d'utiliser des contournements (et une proposition d'inclure dans un fichier texte les contournements a été refusée aussi), d'où cet article. Il suffit de construire un paquet avec equivs, suivant le modèle ici présent :

machine# cd /tmp; cat > gnupg-agent-local.ctl << EOF
Package: gnupg-agent-local
Provides: gnupg-agent
Depends: seahorse
Conflicts: gnupg-agent
Description: Replaces gnupg-agent by seahorse
 A package which allows to use seahorse instead of gnupg-agent.
EOF
machine# equivs-build gnupg-agent-local.ctl
machine# dpkg -i gnupg-agent-local_1.0_all.deb

C'est un peu dommage d'avoir à construire des rustines de ce genre, mais ça marche (c'est ce qu'on demande aux rustines). Ça m'évite d'avoir à fabrique à chaque nouvelle version de kleopatra un paquet strictement équivalent ou la manipulation du fichier control était faite (bien que ce ne soit pas si compliqué que ça, merci à dpkg-repack).

J'ai enfin réussi à comprendre comment paramétrer complètement son bip système avec pulseaudio. Je ne dis pas que c'était compliqué, mais bon.

Le son joué par défaut (une sorte de gloup) est référencé (sous Debian) dans /etc/pulse/default.pa (près de la ligne 87) avec quelque chose qui ressemble à load-sample x11-bell /usr/share/sounds/gtk-events/activate.wav. Le volume par défaut est simplement le volume du bip dans les propriétés X11. Hélas, ce n'est pas changeable dans les préférences de Gnome, mais un simple xset b 100 est suffisant à le mettre à 100% dans un programme lancé au démarrage de Gnome (Système -> Préférences -> Sessions). Si le volume par défaut de 50% est suffisant, autant ne pas le changer (je le trouve trop faible par rapport à ma musique).

La première chose à faire est de supprimer le bip ordinaire : en tant que root, ajoutez à /etc/modprobe.d/myblacklist (ou bien créez le fichier avec) la ligne blacklist pcspkr. Ensuite enlevez le module noyau pcspkr avec rmmod pcspkr (une fois suffit).

Être root et éditer /etc/pulse/default.pa n'est pas très pratique, mais pactl donne à n'importe quel utilisateur le moyen de changer (y compris à la volée) son bip :

#!/bin/sh
# fichier sauvé comme ~/bin/setbeep et lancé au démarrage
xset b 100
SOUND="${1:-/data/macossounds/Quack.wav}"
if [ ! -f "${SOUND}" ]; then SOUND="/data/macossounds/${SOUND}.wav"; fi
if [ -f "${SOUND}" ]; then pactl upload-sample "${SOUND}" x11-bell; fi

Je peux maintenant enfin réentendre de vieux tubes récupérés sur un vieux Macintosh, comme "Quack" ou "Boing"... ou encore faire jouer une chanson de trois minutes à chaque appui malencontreux sur une mauvaise touche !

PS: Pour des raisons légales évidentes, je ne peux pas mettre ici ces bips fabuleux, mais je ne doute pas qu'un esprit un peu curieux et affûté soit capable de les retrouver sur Internet...

Avec le développement des lignes ADSL à haut débit, il est de plus en plus facile de gérer chez soi son serveur. Même si ce n'est pour distribuer que peu de choses, comme des statistiques de surveillance ou autre, il y a des choses qu'on n'a pas envie de confier à un fournisseur externe (par exemple, les photographies personnelles, un agenda privé, etc.). Si les problèmes de débits ne sont pas un obstacle, il y a parfois des difficultés techniques liées purement aux protocoles utilisés.

C'est le cas qui se présente lorsque l'on veut faire un hébergement sécurisé (https) par exemple dès qu'on installe un service qui va demander un mot de passe. Par construction, il est difficile de faire cohabiter plusieurs services derrière un https avec un nom de domaine différent pour chacun.

Je vais expliquer comment j'arrive à générer des certificats auto-signés qui permettent d'identifier plusieurs noms de domaines comme étant valides pour une seule machine.

En effet, le protocole https est le même que le protocole http à une nuance près : avant même de communiquer entre eux sur le service demandé, les ordinateurs commencent par vérifier que le fournisseur du service est bien celui qu'il prétend. Une fois que cette vérification a été faite, les deux ordinateurs décident de crypter toutes leurs communications relatives au service (par exemple, des échanges de mot de passe) de façon à ce qu'un ordinateur au milieu de la communication ne puisse pas écouter et enregistrer les communications pour avoir accès à ces données. Il y a toujours des ordinateurs au milieu de vos communications, par exemple ceux de votre fournisseur d'accès (qui ne sont pas immunisés à des attaques hostiles de la part de pirates).

La technique est simple. Lorsqu'on parle à un ordinateur pour lui demander un service (par exemple : https://galerie.dubacq.fr pourrait être le nom de domaine auquel répond mon ordinateur pour présenter une galerie), celui-ci commence par présenter un certificat X509 garantissant qu'il est galerie.dubacq.fr. Je vais expliquer seulement le cas où c'est lui-même qui garantit cette exactitude (un certificat auto-signé). L'autre méthode est de faire signer le certificat par une autorité directement connue de votre navigateur web et la procédure est assez proche (mais dépend d'une société tierce, donc je ne vais pas m'étendre : c'est leur rôle).

La difficulté commence au moment où un ordinateur veut servir à la fois galerie.dubacq.fr et jean-christophe.dubacq.fr (ce blog) de façon sécurisée. En effet, comme aucune requête spécifique ne vient dire quel est le service demandé avant la vérification du certificat, on ne peut pas envoyer un certificat distinct selon que le service demandé est l'un ou l'autre. On est obligé de présenter un certificat qui présente deux noms (ou plus) avant de pouvoir communiquer pour savoir lequel des services est réellement demandé. Or la spécification X509 ne propose par défaut qu'un seul nom. Heureusement, une extension permet d'en mettre plusieurs. Il suffit de le savoir, et de comprendre la documentation (à la fois complète et complexe) qui va avec.

Voilà le script que j'ai fait qui me fabrique un certificat auto-signé tout propre pour un ou plusieurs domaines. Mon script garde tous les morceaux intermédiaires. J'espère qu'il sera utile à quelqu'un. Évidemment, un certificat auto-signé a ses limites (il repose sur le fait que l'utilisateur accepte une première fois le certificat à un moment où il est sûr qu'il est valide). Mais il n'y a pas à l'heure actuelle de certificat gratuit accessible au particulier et reconnu par défaut par les navigateurs web.

Le script est livré avec un petit fichier auxiliaire indispensable pour son bon fonctionnement, il ne faut pas hésiter à modifier les valeurs par défaut qui sont dedans. Il n'y a pas besoin d'être super-utilisateur (administrateur) pour exécuter ce script, mais il y a probablement besoin de l'être pour utiliser les fichiers produits.

Il est à noter qu'il y a en fait plusieurs fichiers produits: les trois plus utiles sont la clé non-protégée (extension key, à garder précieusement), le certificat proprement dit (extension crt qu'on doit rendre le plus public possible) et le certificat combiné (extension pem) qui regroupe les deux précédents (certaines applications de serveurs préfèrent ce format à la donnée des deux autres).

Je recommande que tous les serveurs en https aient une page web visible et trouvable qui donnent ces certificats à télécharger. Cela permet aux utilisateurs de les télécharger directement depuis un endroit sûr pour les utiliser plus tard dans un environnement hostile.

Au cas où votre fournisseur ne vous donne pas de page web avec le certificat, il est toujours possible de le récupérer (autant pour https que pour d'autres protocoles comme imaps ou pops qui servent à relever le courrier électronique). La commande suivante (sous linux ou autre système avec openssl installé le fait :

SITE="www.example.org"; PORT=993
openssl s_client -connect $SITE:$PORT -showcerts  $SITE.crt </dev/null | sed -ne '/BEGIN CERTIFICATE/,/END CERTIFICATE/ p' > $SITE.crt

Après la stabilisation de la nouvelle version de Debian (intitulée etch), la sortie d'une mise à jour pour la version stable précédente (sarge), et l'élection en tant que Debian Project Leader de Samuel Hocevar, tout ceci le week-end du 8 avril, il a été fait une release party à Paris le 11 avril 2007. Avec un rendez-vous dans le bar Murphy's bar (tout à fait correct, mais au sous-sol trop petit), nous sommes allés finir la soirée au Pizza Pino voisin...

Voici les quelques photos (à peine récupérables) tirées de cette soirée :

Il faut bien comprendre que les toilettes étaient encore plus au fond. On s'est fait détester au son de « La prochaine fois, réservez ! ».

xaiki et sam discutaient dans l'escalier.

Un échange de clés improvisé a fait sortir les ordinateurs en attendant de manger (xaiki, pterjan et lool).

On a fini par pouvoir manger des pizzas.

Plusieurs services (Apache, Tomcat, etc.) dépendent de variables d’environnement, notamment des variables LC_*/LANG*. Il faut donc prendre garde à la façon dont on (re)lance un service. Par exemple, sous Debian, un apache(2)ctl start ne revient pas au même qu’utiliser un “wrapper” comme /etc/init.d/apache(2). Mais il ne suffit pas d’utiliser systématiquement les scripts init.d : toujours sous Debian, /etc/init.d/tomcat5.5 peut dépendre de variables d’environnement. Concrètement, relancer un service depuis un shell avec un environnement particulier peut donc changer son comportement (dates incorrectes, problème de charset, etc.). D’ailleurs, au passage, sous Debian, il est conseillé d’utiliser systématiquement /etc/init.d/apache2 (et non apache2ctl) pour Apache car celui-ci réinitialise l’environnement, et une astuce pour Tomcat est d’exporter les variables voulues (notamment celles concernant la locale) dans le fichier /etc/default/tomcat5.5.

En règle générale, la relance de services sur un serveur en production s’effectue par sudo et/ou SSH. Pour éviter les erreurs d’inattention, il est donc préférable ne pas conserver les variables LC_*/LANG*. Avec sudo, il est ainsi recommandé d’utiliser env_reset pour des raisons de sécurité, mais env_reset conserve ces variables sans qu’il soit possible a priori de les supprimer avec env_delete (voir bug Debian #392321). Au niveau de SSH, on peut agir plus efficacement, comme éviter que ces variables soient envoyées par le client SSH en retirant la directive SendEnv LANG LC_* dans le fichier /etc/ssh/sshd_config. On peut également le faire au niveau du serveur en évitant la directive AcceptEnv LANG LC_* dans le fichier /etc/ssh/sshd_config. Bien sûr, comme toujours toutes ces “astuces” ne doivent pas être appliquées sans précaution ; le principal est de garder en tête que certains services peuvent dépendre des variables d’environnement et d’éviter de les (re)lancer depuis un environnement modifié.

Transformer des heures du dimanche après-midi en giga-octets, c’est possible :

/dev/md0              294G  113G  167G  41% /data

# mdadm --add /dev/md0 /dev/sdd1
# mdadm --grow /dev/md0 --raid-devices=4

Quelques heures plus tard …

# fsck.ext3 /dev/md0
# resize2fs /dev/md0

Et, oh bonheur, y a tout plein de giga en plus, yeehee :

/dev/md0              441G  113G  310G  27% /data

Mise Ă  jour du 26. fĂŠv.

Pour utiliser tout cet espace je me suis dit qu’avoir un miroir Debian Ă  la maison ça peut ĂŞtre super agrĂŠable (8mo/s pour l’apt-get upgrade du matin c’est bon) et puis aussi parceque ça va surement me servir pour mes occupations de dĂŠveloppeur Debian. J’ai toujours eu envie de faire des trucs dans le scope de l’archive et ça sera l’occasion (genre recompiler tous les paquets Perl avec Perl 5.10 par exemple).

Bref, tout ça pour dire, que si vous voulez monter un miroir debian, y a une vraie perle pour tout faire pour vous : apt-mirror. C’est ĂŠcrit en Perl, ça fait des threads, ça se configure en deux temps trois mouvement et ça marche pour ainsi dire tout seul. Bref, c’est gĂŠnial.

Miroir, miroir, dis-moi que ton archive est la plus belle !

Voici quelques nouvelles de GForge en français, pour changer, parce qu'il y a visiblement un fort contingent d'utilisateurs francophones de GForge. Si le blabla ne vous intéresse pas, sautez quelques paragraphes, y'a une annonce qui peut vous intéresser.

Je m'en doutais un peu à vrai dire : je savais déjà qu'il y avait des instances de GForge en usage dans un certain nombre d'entreprises et d'administrations françaises. Je déplorais d'ailleurs que ces usages soient privés, voire secrets... On n'en entendait parler que par la bande, au détour d'une conversation. Et chacun avait ses bricolages locaux, et ses améliorations personnelles, dont personne ne profitait.

Heureusement, les différents utilisateurs francophones de GForge (de forges en général) ont fini par plus ou moins se retrouver, et des discussions ont commencé sur la liste Picolibre Forges. On s'aperçoit donc que de nombreux utilisateurs existent, qu'ils ont souvent des besoins communs, et que certains ont même déjà des solutions à apporter à certains de ces besoins. Il se pourrait bien que ces utilisateurs (et ces développeurs) se mettent à communiquer et à relancer une vraie dynamique de communauté autour de GForge (pour l'instant, il y a une poignée de développeurs, et quelques utilisateurs qui ne communiquent pas, donc j'hésite à appeler ça une communauté). Quelques-uns de ces utilisateurs et moi-même nous sommes rencontrés à la conférence Qualipso la semaine dernière, normalement nous devrions nous retrouver au salon Solutions Linux la semaine prochaine, et une réunion spéciale forges est même organisée après ça. Donc, ça prend forme.

Concrètement, ce que j'espère principalement est que les modifications de chacun seront partagées, de sorte qu'elles puissent être intégrées au cœur de GForge, et portées sur une version plus récente (puisque l'immense majorité des utilisateurs actuels sont basés sur une version 4.5.x patchée). Le « tronc » Subversion de GForge devrait donc intégrer, dans un futur que j'espère pas trop lointain, les évolutions suivantes :

• Intégration du bug-tracker Mantis : au moins deux (et vraisemblablement trois) entités ont déjà réalisé cette intégration, et j'essaie de récupérer les patches pour que tout le monde en profite. Pourquoi tout le monde se focalise sur l'intégration d'un nouveau tracker au lieu d'exploiter la flexibilité de celui de GForge pour l'étendre, ça me dépasse, mais je ne suis pas là pour juger. De même, je trouve vraiment dommage que ce développement ait été fait deux ou trois fois de manière indépendante et sans concertation. Vous avez dit gaspillage de temps humain ?

• Ajout d'un système d'intégration continue (on me dit « Maven »). Là encore, normalement ça a déjà été fait, il ne devrait plus rester qu'à publier les patches et les porter vers l'état actuel du code.

• C'est peut-être lié à l'item précédent (je manque de détails), mais on devrait aussi voir apparaître une intégration dans GForge d'un système de tests automatisés.

...et je ne doute pas que d'autres utilisateurs, qui ont eux aussi ajouté leurs propres fonctionnalités sans rien dire à personne, vont aussi se révéler au grand jour et collaborer avec la communauté (n'est-ce pas ?). Peut-être même que des gens vont remettre au goût du jour l'empaquetage RPM, abandonné depuis plusieurs années.

Histoire de ne pas être en reste, je fais ici l'annonce publique suivante : le plugin Mediawiki pour GForge est enfin publié. Ce plugin fait suite à une intégration faite « avec des contraintes de temps assez serrées » (comprendre « un peu à l'arrache ») pour un client, et à une autre intégration faite plus proprement pour un autre client. Le dépôt SVN de gforge.org contient donc présentement le code qui va bien, et la prochaine version des paquets Debian qui seront publiés fournira un nouveau paquet binaire appelé gforge-plugin-mediawiki. Je dispose également d'une version du plugin pour GForge 4.5.x, mais comme Mediawiki nécessite PHP 5, il faut également extraire de ma branche client la conversion PHP 4 → PHP 5 de GForge 4.5 (et en retirer les fonctionnalités réellement spécifiques au client), ce qui explique que ce n'est pas encore publié sur mon dépôt APT (ni déployé sur Alioth). J'y travaille, promis.

Je m'aperçois que quand je cause d'outils de suivi de version, il m'arrive de mentionner, en plus des standards (CVS, Subversion, Bazaar et les autres), le vénérable CPOLD. Et que souvent, mes interlocuteurs ne connaissent pas CPOLD. Et effectivement, ce n'est guère documenté dans la littérature et le web multimédia mondial. Je m'en vais donc vous présenter un peu cette formidable méthodologie de suivi de versions.

Pourquoi formidable ? Parce qu'elle ne souffre d'aucun des problèmes récurrents des autres outils :

• pas de format de fichier complexe et susceptible de corruption ;
• pas de conflits ;
• aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues) ;
• aucune limitation sur la gestion des branches ;
• une rapidité insurpassable ;
• une simplicité de mise en œuvre et d'apprentissage enfantine ;
• pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles) ;
• des sauvegardes facilitées ;
• etc.

Pour résumer, CPOLD, c'est la poudre verte du suivi de versions. Mais alors, comment ça marche ? Très simplement. Tout répertoire contenant des fichiers est déjà une archive CPOLD, pas besoin d'initialiser quoi que ce soit. Pas besoin non plus de « prendre la main » sur un fichier avant de l'éditer. Une seule commande à retenir, celle pour créer une nouvelle version de ce fichier :

cp fichier fichier.old

Bien entendu, le .old peut être remplacé par n'importe quel suffixe ou combinaison de suffixes, il suffit de définir une convention de nommage et de s'y tenir. On pourra ainsi avoir fichier.old.test.2, la troisième révision archivée de fichier dans une branche « test ». Ou, lorsque les contraintes sont moins marquées ou moins fortement ressenties par l'équipe de développement, on pourra être moins strict. Un « dépôt » CPOLD pourra alors se présenter sous la forme suivante :

roland@mirexpress ~/cpold-demo $ ls
fichier                    fichier.OK             fichier.old.old
fichier.1999-08-16         fichier.old            fichier.old.test-roland
fichier.2003-10-27.valide  fichier.OLD            fichier.prod
fichier.a-verifier         fichier.old.marchepas
roland@mirexpress ~/cpold-demo $

Alors évidemment, ce système présente quelques inconvénients, dus principalement à sa simplicité. Mais il reste tout-à-fait utilisable dans des environnements de production, j'en veux pour preuve le nombre d'entreprises qui ne jurent que par lui et n'en changeraient pour rien au monde. CPOLD, le premier outil de suivi de versions du monde, est sans doute aujourd'hui encore parmi les plus utilisés. Il a su s'adapter depuis les copies de bande magnétique à bande magnétique, a vécu son heure de gloire à l'époque des disquettes, et continue vaillamment son aventure (avec un potentiel décuplé) à l'heure des mémoires Flash et de l'Internet.

Bon, ceci dit, personnellement je préfère Bazaar, et je ne mentionne pas CPOLD parmi les services que je propose habituellement à mes clients (si ce n'est pour leur proposer une migration depuis CPOLD vers autre chose).

Bon, ça y est le jeu concours pour gagner les dix exemplaires du Cahier de l’Admin Debian est clos. Les gagnants ont été prévenus par courrier électronique et les autres peuvent voir qui a gagné sur la page du jeu.

Parmi les 10 gagnants, ceux qui ont été sélectionnés par les auteurs sont : Linux et les choses, le blog de Sun WuKong et Planète Béranger.

Félicitations aux heureux gagnants ! Pour les autres, merci quand même d’avoir participé et j’espère pouvoir rencontrer certains d’entre vous au salon Solutions Linux où je serai présent (sur le stand Debian évidemment).

Vous aurez aussi remarqué que je ne poste plus très régulièrement sur mon blog, ce n’est pas faute de manquer d’idées, mais je passe tellement de temps à travailler sur dpkg qu’il ne m’en reste plus pour rédiger des articles. Ceci dit mes priorités évoluent (par cycle de quelques mois) et un jour ce blog redeviendra un peu plus actif.

Je n’ai pas oublié mon idée de bloguer sur des migrations Sarge->Etch qui le méritent. Voici donc un deuxième volet avec un petit serveur d’entreprise comprenant les services suivants : OpenLDAP (annuaire, authentification), PostgreSQL, NFS, messagerie (Postfix, Courier-IMAP, Amavisd-new, ClamAV, Bogofilter, DCC, Razor, SpamAssassin, Whitelister, Postgrey, Sympa), Apache/PHP (eGroupWare, webmail Horde, wwsympa, logiciels/sites sur mesure) ainsi qu’un certain nombre de logiciels/scripts sur mesure. J’ai donc profité des jours autour de Noël (période idéale pour les migrations de serveurs d’entreprise) pour m’attaquer à cette tâche.

Tout d’abord, je souligne que cette migration est particulière car j’en profite pour basculer sur du RAID (software) et il s’agit donc de réinstaller un système de base et de gérer les migrations “à la main” (tout en jetant un coup d’oeil sur certains maintainer scripts). Au passage, quelle horreur d’ajouter des disques supplémentaires dans un serveur D3LL format tour quand ça n’a pas vraiment été prévu : une seule paire de glissières, uniquement deux emplacements 3″5, alors que techniquement on pourrait mettre une bonne douzaine de disques… Bref, une fois les soucis matériel gérés (ah oui, la nappe SCSI et la terminaison prévues étaient foireuses), la nuit est bien avancée et je peux couper les services et me lancer dans une réinstallation de base puis re-brancher l’ancien disque et gérer service par service la migration. Voici la liste des points critiques et problèmes rencontrés :

- Au niveau du noyau, aucun problème en vue car je reste avec le même (un noyau personnalisé avec notamment le patch grsecurity). Néanmoins, un petit soucis avec la bibliothèque liblzo notamment utile à lynx (…utile à mutt pour voir les messages HTML et diverses pièces jointes) :

$ lynx
lynx: error while loading shared libraries: liblzo.so.1:
cannot enable executable stack as shared object requires: Permission denied

La solution est de “mettre un coup de pioche” dans la bibliothèque :

aptitude install prelink && execstack -c /usr/lib/liblzo.so.1.0.0

- OpenLDAP
Il faut bien gérer le passage du service slapd qui n’est plus lancé par root mais par un utilisateur openldap. Lors de la migration, il faut donc bien ajuster tous les droits (schémas LDAP, ré-injection des données avec slapadd, etc.) sinon slapd vous “segfault” dans la tête ; et ajuster le pidfile dans le slapd.conf (le mettre dans un répertoire /var/run/slapd/ où l’utilisateur openldap aura les droits pour créer le pidfile, et non plus simplement /var/run/).

- PostgreSQL
J’ai utilisé le paquet pour avoir une version 7.4 et minimiser les impacts potentiels lors de la migration car Sarge utilisait déjà une version 7.4. Un pg_dumpall dans le chroot de la machine arrêtée et un psql plus tard, aucun soucis à relever. Il a ensuite suffi de migrer les fichiers de configuration pg_*.

- Bind
Rien à sigaler de particulier, à part installer le paquet bind9, lancer mon fameux script chroot-bind.sh, et transférer l’ancienne configuration (named.conf, rndc.conf, etc.).

- Messagerie (Postfix, Courier-IMAP, Amavisd-new, ClamAV, SpamAssassin, Whitelister, Postgrey, Sympa)
Un gros morceau mais tout se passe bien dans l’ensemble pour ces logiciels extrêmement utilisés. Pas de soucis pour Postfix en reprenant l’ancien fichier main.cf. Pour info, j’utilise souvent debian-volatile (donc SpamAssassin, ClamAV et Postgrey en sont issus) et un Whitelister patché pour vérifier aussi les reverse DNS. À noter que pour pas mal de logiciels, je suis reparti de la configuration de Etch et j’ai importé mes modifications plutôt que de repartir de ma configuration pour Sarge (pour amavisd-new, il n’y a pas trop le choix de toute façon).

- Sympa
Là, ce fut un gros morceau de la migration, parce qu’il y a beaucoup de changements de la version 4 à la version 5. J’ai donc importé les configurations des listes et Sympa s’est débrouillé pour avaler tout ça et injecter les admins des listes dans PostgreSQL. Pour les archives, il faut bien penser à re-générer toutes les archives (par wwsympa) pour avoir le nouveau format car l’ancien s’affiche très mal (plein de variables sensées ne pas s’afficher apparaissent). Enfin, pour injecter les utilisateurs dans les tables user_table et subscriber_table (pour les listes qui n’utilisent pas LDAP ;), j’ai du ajouter la colonne robot_subscriber à la main avant d’injecter le tout. Mais après avoir bien ajusté la configuration et redémarré plusieurs dizaines de fois Sympa, tout marche ! Il ne reste plus qu’à activer fcgi, ajouter un petit patch trivial, refaire les couleurs (car l’interface web change complètement et les *_color deviennent des color_n) et tout roule ! Résultat ici.

- Apache/PHP
Afin de minimiser les impacts, j’ai choisi de rester en PHP4 (la migration en PHP5 se fera par la suite, une chose à la fois). Pour la migration des VirtualHosts (une bonne vingtaine), tout se passe plutôt bien à part le changement des directives pour l’authentification via LDAP déjà indiqué précédemment. Passons aux webapps. Pour eGroupWare, c’est vite vu car c’est géré indépendamment de Debian (il n’y a d’ailleurs pas de version d’eGroupWare pour Etch). De la même façon, pour les sites/logiciels développés sur mesure, rien à signaler. Reste le webmail Horde où les dernières versions apportent un ergonomie bien confortable (options intégrées dans la sidebar, dossiers virtuels, etc.) et une amélioration notable des performances IMHO. Je n’ai pas utilisé la version d’Etch mais directement la version de sid qui corrige un bug d’affichage pour Opera et IE7.

Dans l’ensemble, ce fut long, mais au final pas d’accrochage majeur. Les premiers retours des utilisateurs semblent concluants : tout marche aussi bien (voire mieux puisqu’il y a de nouvelles fonctionnalités/optimisations).

Vous êtes déjà probablement au courant vu que tout le monde en a déjà parlé, mais je vais quand même faire mon billet dessus : Free propose, depuis quelques jours, de l'IPv6 (presque) natif à ses abonnés dégroupés. Plein de sites ont repris l'annonce, je vais pas la copicoller une énième fois, mais je vais apporter quelques détails.

D'abord, comment on le fait marcher ? Dans le cas de monsieur tout-le-monde, il suffit de cliquer sur l'interface de gestion de l'abonnement et de rebooter la Freebox. Si un ordinateur classique est branché dessus, il se verra attribuer une adresse IPv6 (et même plusieurs) en plus de l'adresse IPv4 habituelle. Pouf, un monde nouveau s'ouvre à lui.

Mais, la question que tout le monde pose, à quoi ça sert ? Principalement à affecter à chacun des ordinateurs branchés sur la Freebox une adresse distincte. Beaucoup pensent encore qu'il s'agit d'un gadget qui ne sert à rien sinon à quelques geeks, et que ça n'a aucun intérêt pour madame Michu. Et du coup, ils dénigrent à tout va, et refusent d'en entendre parler. C'est bien dommage, pour plusieurs raisons.

D'abord, parce que ne l'oublions pas, ce sont les geeks qui font marcher le monde, pas les marchands de lessive ou les faiseurs d'opinion. Pas de geeks dans les années 70, pas d'informatique dans les années 80. Pas de geeks dans les années 90, pas d'Internet dans les années 2000. Donc quand les geeks disent que certaines choses sont importantes, il est souvent utile de les écouter. Expliquons donc en quoi IPv6 c'est important.

Pour Cécile Berteau, internaute dite moyenne, ça va changer quoi ? Ça dépend. Si elle vit seule et ne se sert de son unique ordinateur que comme d'un Minitel à images, probablement pas grand-chose. Mais sinon, ça peut changer pas mal de trucs. Premièrement, en IPv6 chaque ordinateur a une adresse différente, même « vu de l'extérieur ». Donc son ordinateur, celui de son fils et celui de son mari auront chacun leur adresse. Les connexions réseau initiées par ces trois ordinateurs seront donc facilement identifiables, et ne nécessiteront plus de phase de traduction d'adresse comme à l'heure actuelle (où, vus de l'extérieur, les trois ordinateurs semblent avoir la même adresse). Cette traduction d'adresse réseau ne pose pas trop de problèmes tant qu'on parle de connexions sortantes, puisque c'est la « box » qui s'en occupe et qu'elle sait faire ce qui va bien ; pour les connexions entrantes, c'est nettement plus complexe à mettre en place, puisqu'il faut configurer manuellement la box, et lui dire vers quel ordinateur envoyer les connexions entrantes, en fonction du type de ces connexions. Et bien entendu, un type de connexion sera toujours envoyé au même ordinateur. Pas question donc pour Cécile de se faire appeler en voix sur IP, puisque les connexions de ce type sont envoyées sur l'ordinateur de son fils (qui a aussi annexé les ports correspondant au partage de fichiers, pour publier les enregistrements de son groupe de rock). Ce problème disparaît en IPv6.

Plus précisément, la solution au problème est grandement simplifiée. Parce que même en IPv4 il existe toute une panoplie de bricolages qui font en sorte que ce problème reste gérable. Par exemple pour la voix sur IP, on peut préétablir des connexions sortantes, qui sont maintenues uniquement pour être capables de recevoir des appels. Mais ça ne peut marcher que si les appels passent par un point central, ce qui n'est pas toujours le cas. Et même quand ça l'est, ça ajoute de la complexité et des temps de transport sur le réseau. Si les appels de Kevin Berteau à sa copine du lycée (qui habite à trois rues de là) passent par un serveur aux États-Unis ou à Amsterdam, ça veut dire qu'il y a un délai supplémentaire (et de la charge réseau inutile, mais ça, Kevin s'en moque). Or le délai, en téléphonie, ça cause de l'écho et de l'effet casserole, et c'est un vrai problème concret. Si la connexion va directement de chez les Berteau à chez Cynthia, Kevin pourra dire ses mots doux à sa chérie dans de bonnes conditions. Parce que les deux amoureux ont chacun leur ordinateur qui discutent directement, sans passer par une fibre optique transatlantique surchargée parce que la transpacifique a été coupée par un cargo ou une pelleteuse (ça arrive régulièrement).

Le fait que chaque ordinateur ait sa propre adresse facilite aussi le filtrage des trafics, bien entendu. Si Kevin s'initie à la réalisation de sites web, et qu'il veut mettre un serveur sur son ordinateur, il pourra rendre ce serveur accessible depuis l'extérieur, puisque les connexions entrantes à sa destination sont facilement détectables. A contrario, les connexions vers les Windows des parents seront bien entendu bloquées, pour éviter qu'ils ne se retrouvent infestés de virus. Et les connexions en voix sur IP de Cécile qui appelle sa meilleure amie resteront prioritaires sur la page web du groupe de Kevin. Parce qu'un quart de seconde de retard, c'est à peine perceptible sur une page web, mais ça empêche une conversation téléphonique, donc il faut pouvoir prioriser les trafics selon leur type, donc les identifier facilement.

Je pourrais aussi vous parler de chiffrement et d'authentification de trafic réseau, de fracture numérique entre les pays qui ont des milliards d'adresses IP réservées et ceux qui n'en ont que quelques milliers (ou centaines !), de simplification des mécanismes de routage, de configuration automatique, et de plein d'autres choses vachement importantes mais qui n'ont pas un impact aussi direct sur le fameux « internaute lambda », mais d'autres le font mieux que moi et ce n'est pas le sujet. Je cherche aujourd'hui à expliquer que non, il ne s'agit pas uniquement d'une lubie de geeks, en montrant du doigt quelques problèmes concrets qui existent maintenant et qu'IPv6 permet de résoudre. Gardez à l'esprit que les nouvelles applications dépendent de plus en plus d'un réseau simple, fiable et rapide, et que ces conditions sont de plus en plus complexes à réunir avec IPv4. Surtout si on commence à voir se répandre l'Internet mobile (tiens, encore un truc qui va consommer plein d'adresses supplémentaires).

Alors maintenant, pourquoi cela a tant traîné ? Pourquoi ça continue à tant traîner, d'ailleurs, à part chez quelques fournisseurs d'accès ? Je pense qu'il y a plusieurs facteurs, mais aucun ne me satisfait. « Chez moi ça marche », certes, mais quid des pays émergents (je pense à la Chine et l'Inde, qui vont très bientôt être d'énormes consommateurs d'adresses IP, mais les autres pays ne doivent oas être oubliés) ? Lorsqu'ils seront en IPv6 (obligés, puisqu'il n'y aura bientôt plus de nouvelles adresses IPv4 à leur affecter), devrons-nous rester dans notre confortable cocon IPv4 ? « On trouvera des solutions », comme on en a déjà trouvé. Des bricolages à base de traduction d'adresses, probablement. Peut-être même à plusieurs niveaux. Avec, à chaque niveau supplémentaire, une complexité de mise en place et de maintenance qui augmente les coûts et diminue la fiabilité. « On a encore le temps » et « ça fait des années qu'on nous annonce qu'on va manquer d'adresses et y'en a encore plein », ça me semble irresponsable. Je suis ahuri de constater que les catastrophes annoncées suffisamment à l'avance ne sont pas prises au sérieux par les décideurs. Enfin, « pourquoi se compliquer la vie avec ça ? », ça me fait doucement rigoler (doux-amer, quand même), puisqu'au contraire ça simplifie la vie de tout le monde. Après une phase de migration, certes, mais elle devient elle-même plus complexe au fil du temps. Et « y'a pas de demande », c'est à la limite du malhonnête... La demande, c'est de l'Internet qui marche, dans un sens ou dans l'autre. Effectivement, quand on essaie d'expliquer à madame Michu que IPv6, c'est 128 bits d'adressage, c'est des facilités pour le filtrage, c'est du routage automatique, c'est des tas de choses qu'elle ne comprend pas, elle ne voit pas l'intérêt et a une réaction de rejet, parce que pour l'instant ça marche alors ne touchez à rien. Mais si on lui expliquait IPv4, ça lui ferait peur exactement autant, il me semble. Je me vois mal lui expliquer la traduction d'adresse, par exemple. Donc je ne pense pas que l'argument pèse en faveur de la stagnation ; bien au contraire, puisque ça aura tendance à simplifier les choses.

Voilà. Une fois ces choses dites, je me réjouis que le mouvement semble engagé, et j'espère que cela pourra servir d'impulsion pour d'autres fournisseurs d'accès et de services réseau. J'espère aussi que ces quelques explications auront pu débouter l'idée reçue qu'IPv6 ne sert à rien. Et si vous n'avez pas tout suivi, faites-moi confiance, je suis un geek (et vous pouvez bien utiliser la lessive que vous voulez, ça ne me fait ni chaud ni froid).

Je m’en rends compte que bien que le livre soit disponible en librairie depuis le 29 novembre, je n’ai toujours pas blogué sur le sujet… il faut dire que j’ai été très occupé. Mais rattrapons le temps perdu. Pour ceux qui ne savent pas de quoi il s’agit, la page officielle de présentation du livre est par là. C’est un livre que j’ai écrit (avec l’aide de Roland Mas pour cette 3ème édition) et qui traite de Debian Etch. À mettre entre to