Gregory Colpart’s blog

No persistent /dev/net/tun in xen Linux domU… Hacky workaround is adding

mkdir /dev/net && mknod /dev/net/tun c 10 200

while booting (for example in rc.local or in your init.d script which need it).

For example tun device is useful for SSH VPN. Without it, you will have errors like:

channel 0: open failed: administratively prohibited: open failed

I use Nokia E65 phone and SFR (french mobile phone provider). Note there is at least two possibilities for access: wapsfr (for WAP browsing and AFAIK illimited) and websfr (less restricted but with high-cost level). I will only speak about wapsfr here. For connecting, it’s the same method like Orange SFR with Debian excepted you set wapfr instead of orange.fr in /etc/ppp/peers/gprs-wvdial.conf file. Then you are now connected but access seems restricted to 80 and 443 ports via proxy (NetApp/6.0.7 NetCache appliance announced by HTTP headers). For HTTP browsing, you must change your User-Agent to Vodafone/1.0/HTC_Mercury/1.23.163.5/Mozilla/4.0 for HTTP browsing. Of course, no problem for HTTPS browsing. And for SSH (for example SSH tunnel to have a full Internet access), you can use corkscrew and a SSH server reachable on tcp/443 to bypass the proxy. Just “apt-get” it and launch:

ssh -o "ProxyCommand /usr/bin/corkscrew %h %p %h %p" -p 443 login@your_ssh_server

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

Une fois n’est pas coutume, mais un récent virus (sous Windows bien sûr) est particulièrement agressif. Il se propage via les périphériques amovibles (clés USB, disques USB, cartes Flash, etc.) en copiant les exécutables csrs.exe et rox.exe à la racine du périphérique, ainsi qu’un autorun.inf qui lui permet de les exécuter plus aisément : l’ouverture automatique du périphérique ou le double-clic sur le lecteur infecte l’ordinateur…

Plus embêtant, ces virus infectent actuellement les machines malgré la présence d’un antivirus à jour. D’après nos tests sur plusieurs antivirus (Sophos, Norton, Kaspersky, etc.), le plus efficace est AVIRA ANTIVIR avec une base d’antivirus up-to-date. J’espère que des mises-à-jour sortiront rapidement pour les autres produits car le virus a l’air particulièrement virulent en se propageant dans plusieurs centaines de fichiers sur chaque système. Autre détail “amusant”, il crée une clé dans la base de registre nommée LOL.

À des fins de tests, voici un fichier ZIP (protégé par le mot de passe pimpampoum) contenant le virus : http://gcolpart.evolix.net/docs/virus-csrs.zip

PFW est un frontend web pour PF (OpenBSD Packet Filter). Voici un petit patch indispensable pour permettre d’éditer correctement les règles de NAT (version 0.7.8). D’autres patches suivront peut-être car de nouveaux bugs nous ont déjà été reportés.

I wrote a quick hack for setting charset in PEAR/XML_RSS 0.9.2 (so annoying bug)… and I discovered a similar patch in PEAR bug 2782 :-) and also that beta versions (PEAR/XML RSS >= 0.9.9) fixed it. Note that you need this feature to use ISO8859-1 feed with PEAR/XML_RSS on “UTF8 by default” system (like standard installation of Debian Etch for example).

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 !

Il n’est pas aisé de maintenir un serveur LAMP car les mises-à-jour majeures du système nécessitent un travail important de vérification (et correction) de toutes les applications web. Et cela s’avère carrément impossible dans le cadre d’un serveur LAMP mutualisé où l’on ne peut pas imposer à tous une migration à un instant défini. La seule alternative viable est de mettre en place un second serveur permettant aux webmasters d’avoir deux comptes en parallèle et ainsi de réaliser une migration en douceur.

C’est donc ce cas de figure qui se pose le serveur web-mutu zidane.evolix.net (Debian 3.1, Apache 2.0.54, PHP 4.3.10, MySQL 4.0.24) qui a désormais une espérance de vie très limitée. Tous les hébergés restants sont donc priés de migrer vers hosting.evolix.net (Debian 4.0, Apache 2.2.3, PHP 5.2.0, MySQL 5.0.32) où un compte leur a été créé. Voici un petit concentré des détails techniques sur lesquels il est nécessaire de se concentrer pour cette migration :

• Migration PHP 4.3 vers PHP 5.2 : vous pouvez consulter les pages suivantes 4.x->5.0, 5.0->5.1 et 5.1->5.2 pour voir les évolutions (nouvelles fonctionnalités, incompatibilités, etc.).
• Migration MySQL 4.0 vers 5.0 : vous pouvez consulter les pages suivantes : 4.0->4.1 et 4.1->5.0.
• Charset ISO8859-1 VS UTF8 : il faut prendre garde aux problèmes d’encodage de caractères. Il est désormais conseillé d’utiliser du full-UTF8 (encodage des fichiers, stockage MySQL, content-type des pages HTML, etc.). Notez que MySQL5 offre la possibilité de stocker ses bases en UTF8, mais cela peut poser des problèmes avec certaines web-applications (des problèmes ont été constatés avec Wordpress, Dotclear) et cela peut nécessiter de convertir votre base. Si les commandes “SET NAMES”, “SET CHARACTER”, etc. vous sont iconnues, reportez vous à la documention MYSQL sur l’internationalisation/localisation.
  
• Pour la gestion des droits, le serveur web d’hosting.evolix.net tourne avec un groupe commun avec votre utilisateur. Vous devez donc vous assurer que vos fichiers sont en lecture pour le groupe pour qu’ils puissent être lus par le serveur web, et en écriture si le serveur web doit écrire dedans.
• En ce qui concerne les modules PEAR, seuls des modules de base sont installés sur le nouveau serveur (Archive_Tar, Console_Getopt, Log, Net_Sieve). Sur demande, nous pourrons installer certains modules supplémentaires ou alors il faudra envisager une installation locale.
• Au niveau DNS, vous avez la possibilité de forcer le pointage vers le nouveau serveur afin de vérifier que tout fonctionne correctement avant de réaliser la bascule réelle de votre site. Si vous souhaitez une bascule rapide en minimisant les délais de propagation DNS, vous pouvez réduire le TTL juste avant le changement effectif (mettez le à 1 heure par exemple, ce qui donnera un délai moyen de 15 minutes pour vos visiteurs).
• Au niveau des statistiques Awstats, vos anciennes statistiques peuvent être récupérées. Il suffit de nous demander de les transférer quelques minutes avant le changement effectif de DNS.

N’hésitez pas à nous contacter par mail ou via le canal IRC #evolix sur Freenode.

I migrate my blog to Wordpress 2.5 and there is a cool feature: widget to have a feed in the sidebar. In the same time, I use now Google reader and I have the possibility to share blog entries with friends: when I find a nice blog entry, I tag it Share and Google reader aggregates all my favorite posts. Unfortunately RSS parser of Wordpress is buggy with this Atom feed from Google reader. You can find a description of the problem in Wordpress forum (titles and links are incorrect because Atom feed could have many tags per item). I write a dirty hack to correct this problem and now you can find “My blogosphere” on the right of my blog.

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 ?