{"id":50,"date":"2008-04-20T03:31:37","date_gmt":"2008-04-20T01:31:37","guid":{"rendered":"http:\/\/gcolpart.evolix.net\/blog21\/?p=50"},"modified":"2009-01-19T00:15:56","modified_gmt":"2009-01-18T22:15:56","slug":"autre-exemple-de-migration-debian-sarge-etch-3","status":"publish","type":"post","link":"https:\/\/gcolpart.evolix.net\/blog21\/autre-exemple-de-migration-debian-sarge-etch-3\/","title":{"rendered":"Autre exemple de migration Debian Sarge->Etch [3]"},"content":{"rendered":"<p>Un nouvel exemple de migration (apr\u00e8s <a href=\"http:\/\/gcolpart.evolix.net\/blog21\/un-exemple-de-migration-debian-sarge-etch-0\/\">[0]<\/a>,<a href=\"http:\/\/gcolpart.evolix.net\/blog21\/autre-exemple-de-migration-sarge-etch-1\/\">[1]<\/a> et <a href=\"http:\/\/gcolpart.evolix.net\/blog21\/autre-exemple-de-migration-sarge-etch-2\/\">[2]<\/a>) qui concerne cette fois un serveur de messagerie (Postfix\/Courier-IMAP\/OpenLDAP\/Amavis\/SpamAssassin\/Horde) et d&#8217;un intranet (Apache\/PHP\/MySQL) pour plusieurs centaines d&#8217;utilisateurs. La migration a dur\u00e9 environ 3 heures (pizzas comprises) sans accroc majeur mais avec un bon nombre de remarques plus ou moins importantes :<\/p>\n<p>&#8211; Les <em>Release Notes<\/em> dispensent de bons conseils : <em>Backup any data<\/em>, <em>inform users in advance<\/em>, etc. J&#8217;ajoute que je pr\u00e9conise de pr\u00e9voir une p\u00e9riode <strong>d&#8217;arr\u00eat<\/strong> des services d&#8217;au moins une heure avec quelques heures de marge au cas o\u00f9 (dans pas mal de cas, cela peut correspondre \u00e0 pr\u00e9voir cela un soir et se r\u00e9server la possibilit\u00e9 de passer la nuit dessus !). Je dis bien que je conseille d&#8217;arr\u00eater les services (par exemple, mettre en place des r\u00e8gles de firewall les rendant inaccessibles) : en effet prenons l&#8217;exemple d&#8217;un service SMTP, il est n\u00e9cessaire de bien v\u00e9rifier que le syst\u00e8me mis-\u00e0-jour est fonctionnel avant d&#8217;autoriser \u00e0 nouveau les mails entrants (car si un probl\u00e8me survient, on risque de perdre des mails). Bien s\u00fbr, si aucun arr\u00eat n&#8217;est possible, une infrastructure permettant une tol\u00e9rance de panne est s\u00fbrement place et l&#8217;arr\u00eat des services sur une machine ne posera pas de probl\u00e8me.<\/p>\n<p>&#8211; J&#8217;utilise en g\u00e9n\u00e9ral un noyau Linux patch\u00e9 grsec sur les serveurs mail ou web. Et avant une mise-\u00e0-jour majeure, j&#8217;ai pris l&#8217;habitude red\u00e9marrer sur un noyau non-grsec, \u00e0 savoir celui par d\u00e9faut&#8230; sauf quand il ne contenait pas les pilotes du controleur RAID\/SCSI. \u00c0 retenir :-)<br \/>\nToujours au sujet du noyau, apr\u00e8s quelques installations\/d\u00e9sinstallations de noyaux, le paquet <em>module-init-tools<\/em> a disparu, d&#8217;o\u00f9 d&#8217;inqui\u00e9tants messages <em>QM_MODULES: Function not implemented<\/em>. Solution triviale : <em>aptitude install module-init-tools<\/em>.<\/p>\n<p>&#8211; J&#8217;ai perdu mon p\u00e9riph\u00e9rique <em>\/dev\/megadev0<\/em> (correspondant au controleur RAID\/SCSI) que j&#8217;ai du recr\u00e9\u00e9 via <em>mknod \/dev\/megadev0 c 253 0 <\/em> pour avoir un monitoring fonctionnel.<\/p>\n<p>&#8211; Un probl\u00e8me de conflit entre les paquets <em>libfam0<\/em> et <em>libfam0c102<\/em> s&#8217;est pos\u00e9, emp\u00eachant d&#8217;ailleurs de pr\u00e9parer la mise-\u00e0-jour avec un <em>aptitude -d dist-upgrade<\/em> pour t\u00e9l\u00e9charger d&#8217;avance tous les paquets \u00e0 mettre \u00e0 jour (j&#8217;ai finalement du le faire en pr\u00e9cisant les paquets manuellement). Pour forcer la r\u00e9solution de ce conflit : <em>aptitude install libfam0<\/em>.<\/p>\n<p>&#8211; J&#8217;ai obtenu l&#8217;erreur suivante pendant la mise-\u00e0-jour : <em>E: Internal Error, Could not perform immediate configuration (2) on debian-archive-keyring Ack!  Something bad happened while installing packages<\/em>. Pour la r\u00e9soudre : <em>aptitude install debian-archive-keyring<\/em>.<\/p>\n<p>&#8211; Parlons Apache\/PHP\/MySQL. En ce qui concerne la migration d&#8217;Apache, aucun probl\u00e8me. Pour MySQL 4 vers 5, rien \u00e0 noter non plus mis \u00e0 part de bien conserver les mots de passe compatibles avec la v4 (<em>old_passwords=1<\/em>) comme nous le propose debconf. Enfin pour PHP, je suis rest\u00e9 (pour le moment) sur la version 4 car l&#8217;Intranet tourne sous <a href=\"http:\/\/typo3.org\/\">Typo3<\/a> et le module calendrier en place semble \u00eatre incompatible avec PHP5. J&#8217;ai eu par contre une activation &#8220;surprise&#8221; du module eaccelerator dans le php.ini :<em> PHP Warning:  Unknown(): Unable to load dynamic library &#8216;\/usr\/lib\/php4\/20050606+lfs\/eaccelerator.so&#8217; &#8211; \/usr\/lib\/php4\/20050606+lfs\/eaccelerator.so: cannot open shared object file: No such file or directory in Unknown on line 0<\/em><em><br \/>\n<\/em><\/p>\n<p>&#8211; Pour SpamAssassin, mettre \u00e0 jour les <em>require_version<\/em> des r\u00e8gles sur mesure ! Et quelques adaptations mineures (<em>ok_languages<\/em>, <em>use_dcc<\/em> plus valables).<\/p>\n<p>&#8211; Quelques petits coups de pioche \u00e0 mettre :<\/p>\n<p><em>freshclam: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied<\/em><\/p>\n<p>Solution : <em>execstack -c \/usr\/lib\/libgmp.so.3.3.3<\/em><\/p>\n<p><em>Uncaught exception from user code: Can&#8217;t load &#8216;\/usr\/lib\/perl5\/auto\/Quota\/Quota.so&#8217; 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, &lt;DATA&gt; line 225. at .\/add.pl line 26<\/em><\/p>\n<p>Solution : <em>execstack -c \/usr\/lib\/perl5\/auto\/Quota\/Quota.so<\/em><\/p>\n<p>&#8211; Pour garder Vim en tant qu&#8217;\u00e9diteur par d\u00e9faut (aucun troll n&#8217;est cach\u00e9 dans ce point&#8230;), ne pas oublier le fameux <em>update-alternatives &#8211;config editor<\/em><\/p>\n<p>&#8211; Pour Courier-LDAP, la syntaxe a apparemment chang\u00e9 :<em><br \/>\nauthdaemond: You need to specify a ldap server in config file<br \/>\nauthdaemond: authldaplib: error in LDAP configuration file, aborting<\/em><\/p>\n<p>Il faut d\u00e9sormais pr\u00e9ciser LDAP_URI (LDAP_SERVER et LDAP_PORT ne sont plus valables) :<\/p>\n<p><em>#LDAP_SERVER        127.0.0.1<br \/>\n#LDAP_PORT      389<\/em><em> LDAP_URI                ldap:\/\/127.0.0.1<\/em><\/p>\n<p>&#8211; Postfix 2.3 g\u00e9n\u00e8re maintenant par d\u00e9faut des DSN (Delivery Status Notifications) qui peuvent s&#8217;av\u00e9rer g\u00eanantes avec les demandes de confirmation de lecture d&#8217;Outlook. Pour d\u00e9sactiver les DSN, ajouter dans le main.cf : <em>smtpd_discard_ehlo_keywords = silent-discard, dsn<\/em><\/p>\n<p>Voil\u00e0, ce fut donc loin de passer comme une lettre \u00e0 la poste, mais \u00e7a ne fut pas un calvaire non plus. Les services ont \u00e9t\u00e9 r\u00e9activ\u00e9s en temps et en heure, et aucun soucis majeur ne s&#8217;est produit dans les jours suivants. Au serveur suivant !<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un nouvel exemple de migration (apr\u00e8s [0],[1] et [2]) qui concerne cette fois un serveur de messagerie (Postfix\/Courier-IMAP\/OpenLDAP\/Amavis\/SpamAssassin\/Horde) et d&#8217;un intranet (Apache\/PHP\/MySQL) pour plusieurs centaines d&#8217;utilisateurs. La migration a dur\u00e9 environ 3 heures (pizzas comprises) sans accroc majeur mais avec un bon nombre de remarques plus ou moins importantes : &#8211; Les Release Notes dispensent [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9,5,72],"tags":[148,21,20],"class_list":["post-50","post","type-post","status-publish","format-standard","hentry","category-debian-fr","category-evolix","category-french","tag-debian","tag-etch","tag-migration"],"_links":{"self":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts\/50","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/comments?post=50"}],"version-history":[{"count":1,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts\/50\/revisions"}],"predecessor-version":[{"id":154,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/posts\/50\/revisions\/154"}],"wp:attachment":[{"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/media?parent=50"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/categories?post=50"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gcolpart.evolix.net\/blog21\/wp-json\/wp\/v2\/tags?post=50"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}