Archive for the ‘Debian-fr’ Category

Conférence sur la sécurité et l’Open Source

Saturday, November 8th, 2008

À l’occasion du salon Synergie NTIC à Marseille, je suis intervenu environ 20 minutes dans une conférence à propos de la sécurité et l’Open Source. En résumé, j’ai parlé de la façon dont on doit se préoccuper de la sécurité quand on travaille avec des distributions ou logiciels Open Source. Notamment, j’ai parlé :

  • Du célèbre principe de Full Disclosure et de ses limites pratiques (période d’embargo),
  • Des moyens de faire une veille sécurité à propos de logiciels Open Source (listes de diffusion à suivre, etc.),
  • De la façon dont les distributions et logiciels Open Source s’organisent face aux problème de sécurité, en prenant l’exemple de Debian,
  • Du choix entre l’installation par paquets ou ports et l’installation via des sources vanilla,
  • D’exemples concrets de problèmes de sécurité récents : la faille concernant vmsplice dans le noyau Linux et du générateur de nombre aléatoire prévisible dans le paquet Debian openssl.

Vous pouvez télécharger les slides utilisés pour cette présentation (soyez indulgent, je les ai fait rapidement).

Problèmes de rendu avec Iceweasel

Sunday, October 19th, 2008

Avec un ordinateur portable sous Debian Lenny i386, depuis quelques semaines j’avais d’étranges problèmes de rendu qui se produisaient sur plusieurs sites. Par exemple, une barre verticale constituée d’images répétées verticalement se retrouvait en plein milieu d’une page au lieu de rester sur les côtés : voici un exemple typique du bug avec le site http://www.evolix.fr/

Le problème est désormais identifié et fixé grâce à glandium (Mike Hommey), mainteneur Debian d’Iceweasel/xulrunner/libxml2/xebkit/etc. Il s’agit d’un problème entre xulrunner et cairo, et l’installation d’un paquet xulrunner-1.9 modifié, ou mieux, libcairo2 modifié, corrige le problème pour mon ordinateur portable (carte Intel, xorg.conf minimal avec uniquement une entrée spécifique pour la disposition du clavier). Merci glandium !

Debian Beer/Pastis Party

Thursday, September 11th, 2008

Je viens de terminer mon “bizutage” Debian afin de devenir officiellement Développeur Debian. Ce processus est possible lorsque l’on maintient des paquets Debian et que l’on connaît Debian sur le bout des doigts ;-). Concrètement cela nécessite d’être recommandé par un autre développeur Debian puis de répondre à des questions sur le packaging et les procédures Debian, des vérifications techniques, des recherches à propos des licences de logiciels libres, etc. Cela dure en général entre 1 an et 2 ans, et il faut faire preuve de patience ! Le statut de Développeur Debian permet entre autres d’uploader directement des packages dans l’archive Debian, de voter (élection annuelle du leader Debian, résolutions générales), de sponsoriser des packages de mainteneurs non-développeurs ou encore avoir accès à des machines d’architectures particulières (ARM, alpha, MIPS, IA64, Sparc, S390, HPPA, etc.).

Pour fêter cela, rendez-vous lundi 15 septembre 2008 18h au Shamrock Irish Pub situé sur le Vieux Port de Marseille (France). Après une bière (ou un pastis ;-), cela sera l’occasion de discuter voire de signer des clés PGP/GPG.

mount VS cat /proc/mounts ?

Tuesday, June 24th, 2008
% mv /usb/foo /tmp/
mv: cannot remove `/usb/foo': Read-only file system

% mount | grep sdb
/dev/sdb1 on /usb type ext3 (rw)

% cat /proc/mounts | grep sdb
/dev/sdb1 /usb ext3 ro,data=ordered 0 0

“cat /proc/mounts” vainqueur.

Autre exemple de migration Debian Sarge->Etch [3]

Sunday, April 20th, 2008

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 !

Autre exemple de migration Sarge->Etch [2]

Saturday, March 8th, 2008

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 ?

Variables d’environnement et services

Monday, February 25th, 2008

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/ssh_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é.

Autre exemple de migration Sarge->Etch [1]

Saturday, December 29th, 2007

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).

Debian BSP ce week-end

Tuesday, October 2nd, 2007

Ce week-end (29/30 septembre 2007) avait lieu une Debian BSP (Bug Squashing Party) à Dijon. Le principe est que des contributeurs Debian se réunissent dans la vraie vie et virtuellement (principalement par IRC) pour améliorer la qualité de la prochaine version stable. Concrètement, cela se passe en s’intéressant aux bugs de Debian en proposant des patches, éventuellement des NMU (Non Maintainer Upload) et en déclarant de nouveaux bugs trouvés à cette occasion.

Le bilan de ce week-end est d’une centaine de bugs corrigés dont 38 RC (Release Critical). Au menu, les classiques FTBFS (Fail To Build From Source), les soucis avec les Maintainer Scripts (postrm-depends-nonessential) ou encore les vérifications sur les builds successifs d’un paquet (qa-doublebuild). Les statistiques complètes des bugs ouverts/fermés à cette occasion sont disponibles sur le Wiki Debian.

Pour ma part, je n’ai participé que modestement à distance. J’ai notamment travaillé sur les paquets suivants : nc6 (netcat IPv6), rubrica (gestion de contacts pour GNOME), Nagios (fameux outil de monitoring), newpki-server (un petit serveur pour une PKI) et ldapdns (stockage des enregistrements DNS dans un annuaire LDAP). Je trouve toujours fort intéressant de se focaliser presque aléatoirement sur certains paquets. Outre le côté instructif, cela permet de se rendre compte que pas mal de paquets sont assez mal maintenus ou encore qu’une relative uniformisation des Maintainer Scripts serait judicieuse (pour l’instant, chacun fait un peu sa “sauce” dans son coin).

Un exemple de migration Debian Sarge->Etch [0]

Sunday, September 9th, 2007

Depuis qu’Etch est stable, j’ai effectué quelques migrations Debian Sarge->Etch sur des serveurs en production (un serveur mail en frontal qui m’a appris qu’il était préférable de rebooter sur un noyau sans patch Grsecurity avant de migrer, un serveur mail LDAP/Postfix/Courier/Horde, une dedibox et quelques autres) mais finalement assez peu. Ce week-end, j’avais prévu de mettre à jour mon serveur personnel, ce qui n’est pas forcément trivial car j’ai pas mal de services (web, mail, CVS, SVN, NFS, LDAP…), l’installation date de plus de 4 ans (Woody à l’époque) et plusieurs tests/bidouillages/backports sont en place.

Pourquoi attendre autant ? Théoriquement Sarge reste maintenu jusqu’en avril 2008, donc rien ne presse si l’on a pas besoin des nouveaux logiciels d’Etch. Et surtout, j’applique le principe de précaution d’attendre un certain temps afin d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, autant j’ai assez de liberté pour mon serveur personnel, autant je ne suis pas le seul décisionnaire pour des serveurs d’entreprise utiles à plusieurs dizaines ou centaines d’utilisateurs.

Bref, entrons dans le vif du sujet. Mes précautions sont d’effectuer des essais de migration avec un serveur de test, d’avoir des backups tout frais, de couper les services durant la phase de migration et de prévenir les utilisateurs à l’avance des perturbations. Ensuite, j’ai repris les Releases Notes, j’ai adapté mon sources.list puis :

# aptitude update && aptitude upgrade
# aptitude install initrd-tool

Pas de problème particulier à noter jusqu’ici. Ensuite, je dois mettre à jour mon noyau :

# uname -a
Linux serveur 2.4.27-3-k7 #1 Wed Dec 6 00:10:25 UTC 2006 i686 GNU/Linux
# aptitude install linux-image-2.6-k7

Comme prévu, udev a râlé un peu à cause de mon noyau 2.4, mais rien de bien grave. Par contre, cela s’est passé moins bien avec LILO qui a semblé un peu perturbé par tous ces changements :

# lilo
Warning: '/proc/partitions' does not match '/dev' directory structure.
Name change: '/dev/scsi/host0/bus0/target0/lun0/disc' -> '/dev/sda'
Fatal: VolumeID read error: sector 0 of /dev/sda not readable

Je n’avais pas le temps d’investiguer et j’ai décidé de tenter ma chance avec GRUB.

# aptitude install grub && grub-install /dev/hda/ && update-grub

La phase grub-install est très longue mais ça s’est bien passé lors du reboot à la fin de la mise-à-jour.

Ensuite, c’était la mise-à-jour de tout le reste des logiciels :

# aptitude dist-upgrade

Je vous fais grâce des messages/questions debconf et les mises-à-jour des conffiles (à ce sujet, pour info, j’ai pour réflexe de visualiser les différences avant de choisir de garder l’ancienne version ou pas, et je garde des notes pour y revenir en fin de mise-à-jour). Passons maintenant aux divers problèmes rencontrés :

– mod_security

Starting web server (apache2)...
apache2: Syntax error on line 116 of /etc/apache2/apache2.conf:
Syntax error on line 1 of /etc/apache2/mods-enabled/mod-security.load:
Cannot load /usr/lib/apache2/modules/mod_security.so into server:
/usr/lib/apache2/modules/mod_security.so:
cannot open shared object file: No such file or directory failed

Pour des raisons de licence, mod_security n’est plus dans Etch (on peut utiliser les packages upstream si on le souhaite).

– Authentification HTTP avec LDAP

Invalid command 'AuthLDAPEnabled', perhaps misspelled or defined by a module not included in the server configuration

J’ai du adapter mes configurations de la façon suivante :

#AuthLDAPEnabled on
AuthBasicProvider ldap
#AuthLDAPAuthoritative on
AuthzLDAPAuthoritative Off

– Apache-SSL

Syntax error on line 75 of /etc/apache-ssl/httpd.conf:
Invalid command 'TypesConfig', perhaps mis-spelled or defined by a module not included in the server configuration

Il s’agit d’un reste d’une fameuse migration Apache 1->2 ;) Ne l’utilisant plus, je me suis contenté de le supprimer et j’ai ouvert un petit bug pour améliorer le httpd.conf : #441447

– Bugzilla

Could not execute `/etc/bugzilla/localconfig'! ;
make sure permissions are ok. at /usr/share/perl5/Bugzilla/Config.pm line 161.
Compilation failed in require at /usr/share/bugzilla/lib/checksetup.pl line 505.
BEGIN failed--compilation aborted at /usr/share/bugzilla/lib/checksetup.pl line 505.
ERROR: Unable to find /usr/share/bugzilla/debian/params.new

Je n’arrive plus à repoduire ce problème après avoir désinstallé et réinstallé Bugzilla avec dbconfig. On va donc considérer cela comme une solution.

-Authentification LDAP avec Courier

Le fichier authldaprc a légèrement changé de syntaxe :

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

– Serveur NFS

Afin que le service NFS fonctionne correctement, j’ai du temporairement ajouter des autorisations sur udp/817, udp/896 et tcp/4984 sur le firewall du serveur. Je dois probablement revoir mes diverses options pour forcer les ports de mountd, lockd & co. (RPCMOUNTDOPTS, RPCSTATDOPTS et les options lockd.tcpport, lockd.udpport). Vu que cela “juste marche” pour l’instant, j’ajusterai ces paramètres “plus tard”.

– Onduleur sur le port série

Le logiciel Nut ne fonctionnait plus, mais c’était simplement une question de droits sur le périphérique /dev/ttyS0

– Problèmes mineurs

J’obtiens des messages récurrents du kernel :

parport0: FIFO is stuck
parport0: BUSY timeout (1) in compat_write_block_pio
DMA write timed out

Ils sont du à un ancien CUPS qui traînait dans le coin pour une imprimante sur le port parallèle plus branchée depuis un certain temps…

J’ai du remettre Vim en éditeur par défaut :

#  update-alternatives --config editor

Voilà pour cette migration. Rien d’extraordinaire, mais je trouve intéressant de prendre la peine de noter les petits problèmes rencontrés (ne nécessitant pas forcément un rapport de bug) sur mon blog afin d’informer (voire aider ;) d’autres personnes qui pourraient avoir des soucis similaires. Un bon complément des Releases Notes. Je vais essayer de le refaire pour d’autres migrations, et n’hésitez pas à faire de même !